Role hierarchies

With role hierarchies, users can have access to records that are owned by or have been shared with users below their hierarchy. In a few words, the CEO (the person with the highest role) can see any record owned by any user, while the Sales Manager can see records that are owned by or have been shared with sales representatives but cannot see records owned by Service Manager users.

This applies to objects with OWD set to Private or Read Only because of the principle that sharing can grant wider access and not restricted access.

This sharing method can be enabled on the OWD Grant Access Using Hierarchies setting and can only be disabled for custom objects.

To set up roles, go to Setup | Users | Roles:

You can create up to 500 roles for your organization.

Every user should have a role, otherwise their data won’t show up on displays based on their role (such as an opportunities report and forecast rollups).

System administrator users may not have the role set, but it is good practice to fill in this field, especially if these users own records. If a role is not set, it is likely that their records won’t appear on reports/views.

You can always set the highest role (for example, CEO) for administrator users and not care about record visibility since system admins should have the Modify All Data permission, which grants access to the whole organization’s dataset.

To avoid performance issues, no user should be able to own more than 10,000 records. If this is unavoidable (for example, the user is an integration user), assign that user a higher role to avoid complex sharing calculations.

If you have a huge number of roles and users, it is suggested that you use SOAP APIs (for example, a Data Loader) to increase efficiency (at least in the organization setup phase or when users change their role frequently).

Sharing rules

Sharing rules create exceptions for OWD settings and can grant wider access to public groups, roles, and territories.

Before we look at sharing rules in detail, let’s talk about Groups.

Public and personal groups

Groups are sets of users and can contain users, other groups, and all the users in a given role or territory hierarchy (or even the users below that given role/territory, that is, the so-called subordinates).

Your organization supports public groups, which are created by administrators and can be used by any user, and personal groups, which are created by any user and only accessible to them.

Groups can be created for the following reasons:

• For default sharing with sharing rules (only public)
• To share a record with other users (both public and personal)
• To share a Salesforce CRM Content library (only public)
• To assign users to a selected action on Salesforce Knowledge (only public)

Since public groups are involved in sharing calculations to increase system performance, we need to take the following into account:

• Avoid creating groups with few users (use manual sharing instead).
• Don’t adopt groups for users that need frequent move in and out.
• Don’t nest groups for more than five levels deep.
• Enable Grant Access Using Hierarchies on the public group configuration, but only if that group doesn’t include all internal users.

A group can contain the following:

• Users
• Public groups
• Personal groups (available only when creating personal groups)
• Roles (internal and subordinates, or internal and portal subordinates)
• Partner users
• Customer portal users