Guidelines for Success with Roles

Understand key rule behaviors, and apply best practices for success with roles.

Required Editions

Available in: both Salesforce Classic and Lightning Experience

Available in: Professional, Enterprise, Performance, Unlimited, and Developer Editions

For best practices on designing record access in a large organization, see Designing Record Access for Enterprise Scale.

General

• To simplify user management in Salesforce orgs with large numbers of users, enable delegated administrators to manage users in specified roles and all subordinate roles.
• In Salesforce orgs created in Spring ’21 or later, you can create up to 5,000 roles. In orgs created before Spring ’21, you can create up to 500 roles and can contact Salesforce Customer Support to increase this limit.
• Every user must be assigned to a role, or their data won’t display in opportunity reports, forecast roll-ups, and other displays based on roles.
• Put all users that require visibility to the entire org at the highest level in the hierarchy.
• Don’t create individual roles for each title at your company. Instead, define a hierarchy of roles to control access of information entered by users in lower-level roles.
• Create roles only for your current requirements. Don’t create temporary placeholder roles in anticipation of future needs.
• Don’t use reporting requirements to determine what hierarchy levels you need.
• When you change a user’s role, the sharing rules for the new role are applied.
• Salesforce Knowledge users can modify category visibility settings on the role detail page.
• When an account owner isn’t assigned a role, the sharing access for related contacts is Read/Write, provided the organization-wide default for contacts isn’t Controlled by Parent. Sharing access on related opportunities and cases is No Access.
• If your organization uses Territory Management, forecasts are based on the territory hierarchy rather than the role hierarchy.
• To prevent disruptions, avoid changing the role hierarchy during business hours.
• Unless your org uses person accounts for site membership, any site or portal users created are contacts that are related to business accounts. Account owners and internal users above them in the role hierarchy can access data shared with the account’s site or portal users through sharing rules or manual sharing. For example, you have a business account, Acme, that’s owned by an internal user with the Sales Manager role. The Grant Access Using Hierarchies setting is enabled for accounts, because it’s a standard object, so all users with the Sales Manager role and above have access to account records that the site and portal users associated with Acme can access. If you share account records with these users (for example, by creating a sharing rule that targets the All Customer Portal Users group), anyone assigned the Sales Manager role or a role higher in the hierarchy automatically has access to the account records you shared. To avoid sharing record data with internal users who can’t have access, do an audit of roles in your org. Create a different role for internal org users who are owners of accounts that have associated contacts who are site or portal users. Or, share records with site or portal users using a public group that has the Grant Access Using Hierarchies setting disabled.

Performance

• To avoid performance issues, we recommend that no single user owns more than 10,000 records of an object. For users who must own more than that number of objects, don't assign them a role or place them in a separate role at the top of the hierarchy. It’s also important to keep that user out of public groups potentially used as the source for sharing rules.
• To improve performance, minimize the number of levels in your role hierarchy. Eliminate roles that aren't needed, and delete sharing rules that grant access to records already shared via the role hierarchy.

Grant Access Using Hierarchies Setting

• Regardless of your organization's sharing settings, users can gain access to records they don’t own through other means such as user permissions like “View All Data,” sharing rules, or manual sharing of individual records.
• If the Grant Access Using Hierarchies option is deselected, users that are higher in the role or territory hierarchy don’t receive automatic access. But some, such as those users with the View All Records and Modify All Records object permissions and the View All Data and Modify All Data system permissions can still access records that they don’t own.
• If you disable the Grant Access Using Hierarchies option, sharing with a role or territory and subordinates only shares with the users directly associated with the role or territory selected. Users in roles or territories above them in the hierarchies don’t gain access.
• If your organization disables the Grant Access Using Hierarchies option, activities that are associated with a custom object are still visible to users above the activity’s assignee in the role hierarchy.
• If a master-detail relationship is broken by deleting the relationship, the former detail custom object's default setting is automatically reverted to Public Read/Write and Grant Access Using Hierarchies is selected by default.
• The Grant Access Using Hierarchies option affects which users gain access to data when something is shared with public groups, personal groups, queues, roles, or territories. For example, the View All Users option displays group members and people above them in the hierarchies when a record is shared with them using a sharing rule or manual sharing and the Grant Access Using Hierarchies option is selected. When the Grant Access Using Hierarchies option isn’t selected, some users in these groups no longer have access. This list covers the access reasons that depend on the Grant Access Using Hierarchies option.

  These reasons always gain access:

  Group Member

  Queue Member

  Role Member

  Member of Subordinate Role

  Territory Member

  Member of Subordinate Territory

  These reasons only gain access when using hierarchies:

  Manager of Group Member

  Manager of Queue Member

  Manager of Role

  Manager of Territory

  User Role Manager of Territory

• When you deselect Grant Access Using Hierarchies, always notify users of the changes in report results that they can expect due to losing visibility of their subordinates' data. For example, selecting My team's... in the View dropdown list returns records owned by the user. It doesn’t include records owned by their subordinates. To be included in this type of report view, records from subordinates must be explicitly shared with that user by some other means such as a sharing rule or a manual share. So if no records are shared with you manually, the My... and My team's... options in the View dropdown list return the same results.But choosing the Activities with... any custom object report type when creating a custom report returns activities assigned to you as well as your subordinates in the role hierarchy.