Role hierarchy fundamentally works by granting users access to data based on their position within an organizational structure, specifically enabling those higher up to see the data of those below them.
Understanding the Core Concept
At its heart, a role hierarchy is like an organizational chart for data access. It defines levels of authority, allowing users at higher levels to inherit access to data owned or shared by users at lower levels. This is crucial for ensuring that managers, directors, or executives can oversee the activities and data of their teams without needing explicit individual sharing rules for every record.
As the reference states, the role hierarchy opens up access vertically so that users assigned to roles higher in the hierarchy have access to records owned by or shared with their subordinates. This means if a sales manager is above several sales representatives in the hierarchy, the manager can see the opportunities, accounts, and other records owned by those representatives.
Key Principles of Role Hierarchy
- Vertical Access: The primary function is to provide 'upward' access. Users in a role can access data of users in roles directly below them or any role further down in that branch of the hierarchy.
- Data Ownership: Access typically flows based on who owns the record. If a user owns a record, their manager (and managers above them) in the hierarchy can access it.
- Inherited Access: Access granted by the hierarchy is inherited. A user gets access not just to their direct subordinates' data but also to the data of anyone below them in the hierarchy.
- Doesn't Imply Editing Rights: While hierarchy grants view access, it doesn't automatically give users the ability to edit records they don't own. Edit permissions are typically controlled by object permissions (like those in profiles or permission sets) and sharing settings.
Practical Examples
Consider a simple sales hierarchy:
- CEO
- VP of Sales
- Sales Director - East
- Sales Manager - NYC
- Sales Rep A
- Sales Rep B
- Sales Manager - Boston
- Sales Rep C
- Sales Manager - NYC
- Sales Director - West
- ...
- Sales Director - East
- VP of Sales
In this structure:
- Sales Manager - NYC can access records owned by Sales Rep A and Sales Rep B.
- Sales Director - East can access records owned by Sales Manager - NYC, Sales Manager - Boston, and all the reps below them (A, B, C).
- VP of Sales can access records owned by both Sales Directors (East and West) and everyone below them.
- The CEO has access to records owned by the VP of Sales and everyone below the VP in the hierarchy.
Conversely, Sales Rep A cannot access records owned by Sales Rep B, Sales Manager - NYC, or anyone higher up or in a different branch (like Sales Rep C).
Role Hierarchy vs. Sharing Settings
It's important to understand that role hierarchies work in conjunction with, but differently from, other sharing mechanisms:
- Organization-Wide Defaults (OWD): OWDs set the baseline access level for records. Role hierarchy then opens up access beyond the OWDs for users higher in the structure. They never restrict access granted by OWDs.
- Sharing Rules: These grant access to groups of users based on criteria (e.g., all opportunities in California) or ownership. They work alongside the hierarchy.
- Manual Sharing: Allows individual record owners or users with appropriate permissions to share specific records with other users.
In essence, the role hierarchy is a powerful tool for implementing a top-down data visibility model based on your organizational structure, ensuring managers and executives have the necessary access to oversee their teams' data.
