Role Hierarchy
The Salesforce security structure that defines a hierarchy of roles, where users in higher roles automatically gain read access (or read/write, if configured) to records owned by users in roles below them.
Definition
The Salesforce security structure that defines a hierarchy of roles, where users in higher roles automatically gain read access (or read/write, if configured) to records owned by users in roles below them.
In plain English
“Role Hierarchy is the Salesforce security structure that arranges roles in a hierarchy. Users in higher roles automatically gain read access (or read/write if configured) to records owned by users in roles below them. It's how managers see their teams' records.”
Worked example
Pinedale Capital's Role Hierarchy reflects the org chart: SDRs at the bottom report up to AEs, AEs report to district managers, district managers to regional VPs, and regional VPs to the CRO at the top. When sharing rules are set to grant access via the hierarchy, a regional VP automatically sees every record owned by anyone in her region - district managers, AEs, and SDRs alike - without explicit sharing on each record. The Role Hierarchy is what implements the standard "managers see their team's stuff" sharing pattern; it's the backbone of most Salesforce sharing models.
Why Role Hierarchy matters
Role Hierarchy is the Salesforce security structure that defines a hierarchy of roles, where users in higher roles automatically gain read access (or read/write, if configured) to records owned by users in roles below them. The hierarchy supports both 'sales hierarchy' patterns (matching management structure) and 'territory hierarchy' patterns (matching geographic or account-based organization).
Role hierarchy is foundational to record-level security because it enables natural management oversight without requiring explicit sharing rules for every relationship. Without role hierarchy, you'd need to maintain sharing rules for every team and territory; with it, the platform handles upward visibility automatically. Mature orgs design role hierarchies that match actual management and territory structures, reviewing periodically as organizational structure evolves.
How to set up Role Hierarchy
The Role Hierarchy controls record visibility — users above another user in the hierarchy automatically see what that user sees. It is **not** an org chart and is **not** a permission system; it's purely about who-sees-what when the OWD is Private.
- Open Setup → Roles
Setup gear → Quick Find: Roles → Roles.
- Switch to Tree View
Top of the page. Tree View is far easier to work with than List View.
- Click Add Role under the parent role
The hierarchy is purely tree-shaped. Each role has exactly one parent.
- Set Role Name and Display Name
Role Name is API; Display Name is what users see in their User detail. Convention: match a job-title-ish name ("VP of Sales," "Account Executive - West").
- Pick Parent Role
Auto-set to where you clicked Add Role under. Can be changed.
- Configure Opportunity / Case / Contact access overrides
Mostly deprecated — leave at default unless you have a specific reason. These let you tweak whether the role can access opps/cases owned by users without a role.
- Save and assign users
Save the role. Assign by editing User records → Role field, or by Mass Reassign.
Required. Drives the visibility-up rule.
API name.
What appears on user detail pages.
Mostly deprecated overrides. Default is usually correct.
- The Role Hierarchy is for VISIBILITY, not permissions. Permissions come from Profile + Permission Sets. Don't try to model your org chart here unless visibility maps to it.
- Moving a user to a new role moves all their owned records' visibility too — managers above the new role gain access; managers above the old role lose it.
- Deleting a role with users assigned fails. Reassign every user out first, then delete.
How organizations use Role Hierarchy
Maintains role hierarchy matching their actual management structure for natural data visibility.
Uses role hierarchy as the primary mechanism for management oversight, supplemented by sharing rules where needed.
Reviews role hierarchy quarterly as part of access governance.
Trust & references
Straight from the source - Salesforce's reference material on Role Hierarchy.
- Controlling Access Using the Role HierarchySalesforce Help
- Role and Territory Sharing GroupsSalesforce Help
Test your knowledge
Q1. What is Role Hierarchy?
Q2. What does the hierarchy enable?
Q3. What's a best practice?
Discussion
Loading discussion…