Introducing Role Hierarchies
The first way that we can share access to records is by defining a role hierarchy. Similar to an org chart, a role hierarchy represents a level of data access that a user or group of users needs. Users assigned to roles near the top of the hierarchy (normally the CEO, executives, and other management) get to access the data of all the users who fall directly below them in the hierarchy. The role hierarchy enables these behaviors:
- A manager will always have access to the same data as his or her employees, regardless of the org-wide default settings. For custom objects, you can override this behavior by deselecting the Grant Access Using Hierarchiescheckbox. However, we want our role hierarchy to apply to all of our custom objects, so leave the checkboxes selected.
- Users who tend to need access to the same types of records can be grouped together—we’ll use these groups later when we talk about sharing rules.
To illustrate, let’s take a look at a portion of the role hierarchy for Universal Containers:
Role hierarchies don’t necessarily need to match your org chart exactly. Instead, each role in the hierarchy should just represent a level of data access that a user or group of users needs. For example, suppose your organization employs a corporate lawyer who needs to access all of the records in the app. One easy way to accomplish this is by assigning the lawyer to the CEO role in your organization’s role hierarchy. Since the CEO role is placed at the top of the hierarchy, anyone assigned to that role automatically gets full access to any record in the organization. It doesn’t matter that technically the lawyer appears below the CEO in the regular org chart.