The role Hierarchy, as it suggests, is the hierarchy of the roles existing in your Salesforce org. In business terms, a Role is just a job title, or group, that a User can fall into; so for example,
But from Salesforce’s point of view, a Role decided what records a User has visibility to, and what they can do with those records.
The Role hierarchy is used is to move record access up the hierarchy, provided the sharing model for the object specifies it to do so. So let’s pretend we have a custom object called ‘Application’ that has the ‘Grant Access Using Hierarchies’ checkbox checked inside the Sharing Settings, and there is a record, Application 1, that is owned by Jane, a Recruiter (his role).
Jane’s Manager, Joe, has the Role of Recruitment Manager which is above the Recruiter role in the Role Hierarchy, this means Sarah will have access to view all of the records owned by James (and any other User with the Recruiter role), but, Jane does not have access to view Joe’s Application records. This is because Jane’s Role is below Joe’s Role in the hierarchy.
If an object has a Public Read/Write set under the default access, then hierarchies sharing will not be needed as everyone in the org has access regardless, however, if it is set to Private, then granting access through hierarchies will be needed if you’re wanting to open up access to Roles further up. For more information on this, see the table below.
| Profile Access | OWD | Access Through Hierarchy |
| CRED | Private | No Access View View + Edit |
| CR | Private | No Access View View + Edit |
| CRED | Public Read Only | View View + Edit |
| CR | Public Read Only | View View + Edit |
| CRED / CR | Public Read/Write | Not Required |
Considerations
- ‘Grant Access Using Hierarchies’ option is enabled for all objects and it can only be changed for custom objects.
- You can have up to 500 Roles defined in your Salesforce org,
- When a User has their Role changed, the sharing rules are recalculated for the new Role,