Role Hierarchy
A Role Hierarchy in Salesforce is the tree structure of Roles that propagates record access upward through the chain of command.
Definition
A Role Hierarchy in Salesforce is the tree structure of Roles that propagates record access upward through the chain of command. Each Role in the hierarchy has one parent Role (or sits at the top with no parent), and records owned by users in any subordinate Role become visible to users in any parent Role above them. The Role Hierarchy is one of the four mechanisms in the Salesforce sharing model: it sits between Organization-Wide Defaults (which set the base access) and Sharing Rules (which grant additional cross-cutting access).
Role Hierarchy is what makes manager visibility work in Salesforce. Without it, every manager who needed to see their team's records would require a separate Sharing Rule per team member. With it, a Regional VP automatically sees every Opportunity owned by every Manager and every Rep in their branch of the tree, without any per-record configuration. The trade-off is that Role Hierarchy access is broad and automatic; if a manager moves up the tree, they gain access to everything underneath them immediately, including records they may have no legitimate need to see.
How Role Hierarchy propagates record access
Tree structure
A Role Hierarchy is a directed tree with one root node (the top-of-org Role) and as many child nodes as the org needs. Salesforce supports up to 500 levels in theory, but practical hierarchies max out at five to seven levels (Executive, SVP, VP, Director, Manager, Rep). Adding more levels usually signals a modeling problem: either you are trying to capture matrix reporting (which needs Public Groups, not nested Roles), or geographic regions (which often work as parallel branches rather than deeper nesting), or compensation hierarchy (which has nothing to do with access and should not be modeled in Role Hierarchy at all).
Access propagation upward
When a user owns a record (or gets access through any other sharing mechanism), every user in any parent Role above the owner's Role also gets access through the hierarchy by default. The propagation is automatic and recursive: a Sales Rep's records propagate to their Manager, the Manager's Role inherits access from the Reps it contains, the VP's Role inherits from all subordinate Managers, and so on up to the top of the tree. This is what makes the standard "My Team" filter work on every Salesforce report: the filter scopes to records owned by anyone whose Role rolls up to the current user's Role.
Grant Access Using Hierarchies toggle
The Role Hierarchy propagation is configurable per object through Organization-Wide Defaults. Each object has a Grant Access Using Hierarchies setting (on by default) that decides whether Role Hierarchy access propagates. Most objects keep this on because the propagation matches business intent. Some objects need it off: Cases in some support orgs (where managers should not auto-see subordinates' cases), Knowledge Articles in compliance regimes (where only authoring roles should have access), custom objects that model HR or compensation data (where Role-based propagation would leak salary information). Configure this per object during the initial security design, not after.
Forecast Hierarchy
Forecast Hierarchy is a sister structure to Role Hierarchy that decides how forecast roll-ups flow. By default, Forecast Hierarchy mirrors Role Hierarchy, with each manager's forecast aggregating subordinate forecasts up the tree. The mapping is configurable through Setup > Forecasts > Forecasts Hierarchy. Most orgs leave the default in place; orgs whose forecast reporting structure differs from their operational reporting structure (a Global Sales SVP who consolidates forecasts from geographic VPs who report into HR-side leadership) customize Forecast Hierarchy explicitly. The two hierarchies can diverge cleanly when needed, but doing so creates two structures to maintain.
Design patterns and anti-patterns
The cleanest Role Hierarchies follow operational reporting (who approves whose work) rather than HR-style org charts. A "Senior Account Executive" should not have a Role above "Account Executive" if both report to the same manager; they belong in sibling Roles under that manager. Matrix reporting (a rep who reports to both a regional VP and a global product lead) should not be modeled with multiple parent Roles (Salesforce does not support multi-parent in any case); use Public Groups for the secondary relationship. Geographic regions usually work as parallel branches at the same depth, not as nested levels. Keep the depth shallow and the breadth reasonable; the goal is access propagation, not a comprehensive org-chart visualization.
Role changes and the sharing cascade
Moving a user from one Role to another re-cascades sharing across every record they own. The cascade is fast on the platform but invisible to users; reps suddenly see deals they did not see before and lose visibility into deals they used to see. Plan Role changes for after-hours runs, communicate the change to affected reps the day before, and confirm visibility checks the next morning. Mass Role changes (territory realignments, reorganizations) should run through a Data Loader or Apex script that batches the changes, because the synchronous sharing recalculation on a thousand individual Role changes can take hours and back up other platform operations.
Depth limits and performance
Salesforce supports deep hierarchies in principle but each level adds sharing-recalculation cost. The Role Hierarchy depth multiplied by the number of records per branch produces the number of ObjectShare rows the platform maintains, and that table grows fast. Most orgs that exceed seven levels of Role Hierarchy depth see noticeable performance issues on record saves and on Role changes. If your hierarchy needs more depth than that, you are probably modeling the wrong thing; revisit whether some of those levels could collapse into Public Groups or Account Teams.
How to design and build a Role Hierarchy
Configuring a Role Hierarchy is an architectural exercise more than an admin task. The hierarchy you build lives for the life of the org, and changing it after thousands of records have been shared through it produces hours of recalculation and visibility gaps in the meantime. Design carefully.
- Open Setup and navigate to Role Hierarchy
Setup > Users > Role Hierarchy. The default tree view is easier to reason about than the flat list view.
- Map the operational reporting structure on paper first
Sketch out who approves whose work, with named-account books, regional structures, and any matrix relationships. Decide which goes through Role Hierarchy and which goes through Public Groups or Sharing Rules.
- Click Add Role
For each Role, set the Label, the Role Name, the Parent Role, and the Forecast Manager flags if applicable. The Description field is useful for documenting why this Role exists.
- Configure Grant Access Using Hierarchies per object
In OWD (Setup > Sharing Settings), confirm Grant Access Using Hierarchies is enabled (or disabled) for each object. Default is on.
- Assign Roles to Users
Setup > Users > select User > Role. Configure every active User; document any deliberately Roleless users.
- Test with representative users from each branch
Log in as users at different depths (or use Login As) and confirm the access they see matches the intent.
- Plan Role-change runbooks
Document the procedure for moving users between Roles, including communication and after-hours scheduling. Role changes are operationally expensive even when they go cleanly.
- Role Hierarchy is a sharing mechanism, not a job-title mechanism. Avoid mapping HR titles 1:1 into Roles; many titles share the same access pattern.
- Grant Access Using Hierarchies is a per-object toggle. Audit it during security design; default is on but some objects need it off.
- Role changes re-cascade sharing across every record. Plan for off-hours and notify affected users.
- Depth beyond seven levels usually indicates a modeling problem. Most operational structures fit cleanly in three to five levels.
Trust & references
Cross-checked against the following references.
- RolesSalesforce Help
- Control Who Sees WhatSalesforce Help
Straight from the source - Salesforce's reference material on Role Hierarchy.
- RolesSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is Role Hierarchy?
Q2. What does the hierarchy enable?
Q3. What's a best practice?
Discussion
Loading discussion…