Salesforce Role Hierarchy Explained: Structuring Access and Visibility
When Salesforce administrators configure security, one structure determines more about record visibility than almost any other: the role hierarchy. Despite its importance, the role hierarchy is frequently misunderstood, often confused with profiles or permission sets, and sometimes built to mirror an HR org chart rather than actual data access needs.
This article explains what the Salesforce role hierarchy is, how it differs from other access mechanisms, and how to design a hierarchy that scales with your organization. Whether you’re building a new Salesforce org or restructuring an existing one, understanding role hierarchy fundamentals will help you avoid common pitfalls and create a system that supports accurate reporting and appropriate record access.
What Is the Salesforce Role Hierarchy?
The Salesforce role hierarchy is a vertical structure that controls record-level visibility based on user roles. It determines who can see which records by establishing parent-child relationships between roles, so users in higher roles automatically gain access to records owned by or shared with users in lower roles.
This “access up the hierarchy” behavior works in conjunction with Organization-Wide Defaults (OWD), sharing rules, and teams to produce the final access picture for any given record. The role hierarchy does not operate in isolation; it layers on top of OWD settings to extend record access beyond the baseline.
A critical distinction that Salesforce administrators must internalize: roles represent data access levels, not job titles or HR grades. Although many organizations start by mapping roles to their org chart, the role hierarchy should reflect who needs to see whose data, not who reports to whom for performance reviews. Two employees with identical job titles but different data visibility requirements may need different roles.
The role hierarchy also affects reports and dashboards. When a user runs a report filtered to “My Team’s Opportunities,” Salesforce includes records owned by all users in subordinate roles. This makes the hierarchy structure directly visible in day-to-day reporting.
For standard objects like Accounts, Opportunities, and Cases, the “Grant Access Using Hierarchies” setting is always enabled and cannot be turned off. For custom objects, Salesforce administrators can disable this checkbox in Sharing Settings, which prevents the role hierarchy from automatically opening up access. When disabled, access to that object’s records must come from the record owner, explicit sharing rules, teams, or manual sharing.
Roles vs Profiles vs Permission Sets
Understanding the distinction between roles, profiles, and permission sets is foundational to sound Salesforce security design. These three mechanisms serve different purposes and should never be conflated.
Profiles define what a user can do. A profile controls object permissions (Create, Read, Edit, Delete), field-level security, app access, login hours, IP restrictions, and system permissions. Every user in a Salesforce org has exactly one profile, typically aligned with their function, e.g., “Sales User,” “Support User,” or “Marketing User.” The profile answers questions such as “Can this user edit Opportunity records?” and “Can this user see the Revenue field on Accounts?”
Roles define what a user can see at the record level. A user’s role determines their visibility into other users’ records based on hierarchical position. Unlike profiles, roles are optional; a user can have zero or one role assigned. When a user has a role, that role exists within a parent-child hierarchy that structures how record visibility flows upward.
Permission sets and permission set groups add capabilities without changing the profile. These are additive layers that grant extra object permissions, field access, or system permissions. A user can have multiple permission sets assigned. Permission sets cannot restrict access; they only extend what the profile already allows.
Key distinctions to remember:
Profiles and permission sets control capabilities (what actions a user can perform)
Roles control record visibility (whose records a user can see)
Profiles are required; roles are optional
Permission sets are additive; profiles are baseline
A useful memory aid: Profiles and permission sets define capabilities; roles structure record visibility.
One common mistake is attempting to use roles to manage object-level permissions. This does not work. Placing a user higher in the role hierarchy will not grant them edit access to Opportunities if their profile lacks Edit permission on that object. They may see more records, but they still cannot modify them. Object permissions belong in profiles and permission sets exclusively.
How Record Visibility Flows Through the Role Hierarchy
Record visibility in Salesforce starts with Organization-Wide Defaults, which set the most restrictive baseline for each object. For example, a typical sales org might configure:
Accounts = Private
Opportunities = Private
Cases = Private
Contacts = Controlled by Parent
With these settings, users only see records they own unless another mechanism extends access. The role hierarchy opens visibility from bottom to top, granting users access to records owned by users in subordinate roles.
Record ownership drives initial visibility. Each record has an owner (usually a user, sometimes a queue). The owner’s role dictates which managers can see that record through the hierarchy. When an Account Executive owns an Opportunity, their Regional Sales Manager (one level up) and VP of Sales (two levels up) can view that Opportunity, assuming Grant Access Using Hierarchies is enabled for that object.
Consider this example hierarchy:
CEO
└── VP Sales
└── Regional Sales Manager
└── Account ExecutiveWith Opportunities set to Private:
The Account Executive sees only Opportunities they own (plus any explicitly shared)
The Regional Sales Manager sees their own Opportunities plus all Opportunities owned by Account Executives beneath them
The VP Sales sees all Opportunities owned by the Regional Sales Manager and all Account Executives in that branch
The CEO sees all Opportunities across the entire sales organization
This access flows upward automatically. Managers do not need sharing rules or manual shares to see subordinate records; the role hierarchy handles this.
Grant Access Using Hierarchies behaves differently for standard and custom objects. For standard objects like Accounts, Opportunities, and Cases, this setting is always enabled. Salesforce administrators cannot disable it. For custom objects, the Sharing Settings page includes a checkbox to enable or disable this behavior. When disabled, the role hierarchy does not automatically extend access for that object. Users access records only through ownership, sharing rules, public groups, teams, or manual sharing.
The impact on reporting is significant. When a Regional Sales Manager runs “My Team’s Opportunities,” the report includes records owned by all users directly in their subordinate roles. If the hierarchy is misconfigured, perhaps a sales rep is assigned to the wrong role, and the manager’s reports will be inaccurate.
Designing a Scalable Role Hierarchy: Practical Patterns
A well-designed role hierarchy reflects reporting and data visibility needs, not every job title in the company. Below are three patterns that illustrate scalable approaches for different organizational structures.
Example 1: B2B Sales Organization
A global B2B company with regional sales teams might structure roles as follows:
Global VP Sales at the top of the sales branch
Below that: North America Sales Director, EMEA Sales Director, APAC Sales Director
Under each director: Regional Sales Manager (e.g., “NA East Sales Manager,” “NA West Sales Manager”)
At the bottom: Account Executive roles for each region
This pattern supports regional reporting. The EMEA Sales Director sees all Opportunities and Accounts owned by EMEA team members but cannot see North America data. The Global VP Sales sees everything across all regions.
When determining where to place a role, ask: “What should this user’s ‘My Team’s’ reports include?” If a Regional Sales Manager should see data for their entire region but not other regions, they belong above the Account Executives in their region and beneath the Director who oversees multiple regions.
Example 2: Account Management and Customer Success
Customer success organizations often need visibility boundaries between customer segments:
VP Customer Success at the top
Enterprise CSM Manager and Mid-Market CSM Manager as parallel branches
Under Enterprise: Enterprise CSM roles
Under Mid-Market: Mid-Market CSM roles
This structure keeps Enterprise and Mid-Market account data more isolated. An Enterprise CSM Manager cannot see Mid-Market customer health scores or accounts, but the VP Customer Success sees both branches. If a custom object, such as “Customer Health Score,” has Grant Access Using Hierarchies enabled, this pattern works automatically.
Example 3: Shared Services (Sales Operations, RevOps)
Cross-functional roles like Sales Operations present a design challenge. These users often need visibility across multiple branches (all regions, all segments) for analytics and reporting.
Two approaches work:
Place the role high in the hierarchy. Position “Sales Operations Manager” above all regional directors but below the VP. This grants visibility to all subordinate records without giving them a separate branch.
Use system permissions instead of hierarchy. Grant “View All” or “Modify All Data” permissions through a permission set or profile. This provides global access without requiring the user to occupy a specific position in the hierarchy.
The second approach is often cleaner when the user’s job is purely analytical and they should not appear in the same visibility chain as managers who own pipeline.
Design for reporting first. Before building roles, define what “My Team’s” and regional roll-up reports should show. Then map roles to those reporting paths.
Partners like Deselect, experienced in scalable Salesforce org design, typically recommend keeping role hierarchies under 40–50 roles for mid-size organizations. This maintains clarity, simplifies troubleshooting, and supports long-term maintainability.
Role Hierarchy, OWDs, Sharing Rules, and Teams
The role hierarchy is one component of Salesforce’s broader sharing model. Understanding how these mechanisms interact is essential for configuring access that matches business requirements.
Organization-Wide Defaults Set the Baseline
OWD defines the most restrictive default access for each object. A typical sales org might configure:
| Object | OWD Setting |
|---|---|
| Accounts | Private |
| Opportunities | Private |
| Cases | Private |
| Contacts | Controlled by Parent |
With Accounts set to Private, users see only the Accounts they own or that are explicitly shared with them. The role hierarchy then opens up access vertically, managers see records owned by or shared with users in subordinate roles.
Sharing Rules Provide Horizontal Access
Sharing rules extend record access beyond the hierarchical relationship. They enable access patterns that do not follow the manager-subordinate chain.
For example, an owner-based sharing rule might share all Accounts owned by users in the “EMEA Strategic Accounts” role with the “Enterprise CSM” role. This grants CSMs visibility into strategic accounts regardless of who owns them or where the CSM sits in the hierarchy.
Criteria-based sharing rules use field values to determine which records to share. A rule might share all Opportunities where “Deal Size” equals “Enterprise” with a public group called “Enterprise Deal Desk.”
Public Groups Combine Multiple Access Sources
Public groups can include roles, roles and subordinates, individual users, and other groups. They provide a flexible target for sharing rules.
For instance, a “Regional Leadership” public group might include:
All users with the “Regional Sales Director” role (and subordinates)
Specific individual contributors who need cross-regional visibility
Another group containing territory-based assignments
Sharing rules targeting this group extend access to a diverse set of users without modifying the role hierarchy itself.
Teams Provide Record-Level Access
Account Teams and Opportunity Teams grant access to specific records rather than record sets. An Account Team might include:
The Account Owner (an Account Executive)
A Solutions Engineer from a separate technical branch
A Customer Success Manager from the CS branch
Each team member receives a defined access level (Read Only or Read/Write) for that specific account. If Grant Access Using Hierarchies is enabled, the managers of those team members also gain access through the hierarchy.
Concrete Scenario
An Opportunity owned by an Account Executive in the “DACH Sales” role demonstrates how these mechanisms combine:
Role hierarchy grants access to the “DACH Sales Manager” and “EMEA Sales Director” (one and two levels up)
Sharing rule shares the Opportunity with the “Pre-Sales Consultants” public group based on the Stage field
Opportunity Team includes a Solutions Architect who receives Read/Write access
All three access paths coexist. The effective visibility for any user depends on which mechanisms include them.
Configuring the Role Hierarchy in Salesforce Setup
Setting up the role hierarchy requires planning before configuration. Sketch the hierarchy in advance using a whiteboard, spreadsheet, or diagramming tool focused on reporting lines and data visibility rather than HR structure.
Step-by-Step Configuration
Navigate to the Role Hierarchy page. In Setup, use the Quick Find box to search for “Roles.” Select “Roles” under Users to open the Role Hierarchy page.
Create the top-level role. Start with a single role at the apex, typically labeled “CEO” or “Executive Leadership.” This role will have visibility into all records owned by subordinate roles across the organization.
Add functional VP-level roles. Below the top role, create roles such as “VP Sales,” “VP Customer Success,” and “VP Marketing.” Each represents a major functional area with distinct data visibility needs.
Build regional or departmental branches. Under each VP role, add roles representing the next level of visibility segmentation. For a sales organization, this might include “NA Sales Director,” “EMEA Sales Director,” and “APAC Sales Director.”
Add team-level roles. Continue building downward to roles like “Regional Sales Manager” and “Account Executive.” Each level should represent a meaningful visibility boundary.
Assign users to roles. When creating or editing a user record, the Role field determines their position in the hierarchy. Assign roles only where record-level visibility via hierarchy is actually needed; not every user requires a role.
Testing the Configuration
Before deploying changes to production:
Build and test in a sandbox environment (full-copy or partial sandbox preferred)
Create sample users at different hierarchy levels
Log in as each user type and verify which Accounts, Opportunities, and other records are visible
Run “My Team’s” reports to confirm expected roll-up behavior
Document discrepancies and adjust the hierarchy as needed
Restructuring the hierarchy in a production Salesforce org should be planned and communicated. Changes to roles trigger the recalculation of sharing, which can affect performance in large organisations and may temporarily impact what users see.
Common Design Mistakes and How to Avoid Them
Even experienced Salesforce administrators make mistakes when designing role hierarchies. Below are the most common pitfalls, their impact, and how to remediate them.
Mistake: Mirroring the Full HR Org Chart
Impact: Creates hundreds of roles, many with only one user, making the hierarchy difficult to understand, audit, and maintain.
Remediation: Compress levels and create roles only where data visibility or reporting needs differ. Multiple job titles can share a single role if they should see the same data.
Mistake: Using Roles to Manage Object Permissions
Impact: Administrators expect that promoting a user to a higher role will grant edit access to records, but the user still cannot modify them because their profile lacks the necessary object permissions.
Remediation: Keep object and field access in profiles and permission sets. Use roles solely to shape record visibility. A user needs both the correct object permissions (to act on records) and the correct role position (to see records).
Mistake: Creating Deep Hierarchies (5–7+ Levels)
Impact: Complicates troubleshooting, increases the overhead of sharing calculations, and makes it harder for new administrators to understand the access model.
Remediation: Limit the hierarchy to 3–4 levels for most organizations. Use sharing rules and public groups to handle cross-functional access rather than adding hierarchy depth.
Mistake: Giving Senior Executives Roles at the Very Top
Impact: Forces executives who already have “View All” or “Modify All Data” permissions into the role hierarchy, adding unnecessary complexity.
Remediation: If a user has system permissions that grant global visibility, they do not need to sit at the hierarchy apex. Consider leaving them unassigned or using a minimal role that does not affect other users’ access paths.
Mistake: Ignoring Cross-Functional Sharing Needs
Impact: Late in implementation, administrators realize that “Sales” and “Customer Support” branches need to share certain records, requiring rushed reconfiguration.
Remediation: Identify cross-functional sharing requirements early. Use public groups and sharing rules to share records between branches. The role hierarchy handles vertical visibility; sharing rules handle horizontal access.
Mistake: Not Reviewing the Hierarchy After Reorganizations
Impact: The role hierarchy drifts out of alignment with the current operating model. Reports show incorrect data, and users have access they should not have (or lack access they need).
Remediation: Conduct access reviews annually or after significant organizational changes. Partners like Deselect typically run access audits and sharing diagrams to verify that the designed hierarchy matches compliance and reporting requirements.
Tip: Document your role hierarchy design decisions and the rationale behind each role. When reorganizations occur, this documentation accelerates updates and helps new administrators understand the structure.
Key Takeaways
The Salesforce role hierarchy is a powerful but often misunderstood structure. To design and maintain it effectively:
Roles control record visibility, not capabilities. Use profiles and permission sets for object permissions; use roles to structure who sees whose records.
Design for reporting. Decide what “My Team’s” reports should show, then build roles to match those requirements.
Keep hierarchies simple. Fewer roles with clear purposes outperform deep, complex structures that mirror every HR grade.
Combine mechanisms intentionally. Role hierarchy provides vertical access; sharing rules and public groups provide horizontal access; teams provide record-level access.
Test before production. Validate hierarchy changes in a sandbox with sample users and reports.
Review periodically. Organizational changes can render a hierarchy obsolete. Regular audits maintain accuracy.
A well-designed role hierarchy simplifies access management, produces accurate reports, and scales with organizational growth. Whether you’re building a new Salesforce org or optimizing an existing one, the principles in this article provide a foundation for sound structural decisions.
Did this article solve your issue? If you’re evaluating your current Salesforce role hierarchy or preparing for a reorganization, consider mapping your existing roles against the patterns described here. Identify where your hierarchy may be overcomplicating access or where cross-functional sharing rules could reduce complexity. For organizations facing significant restructuring, engaging a Salesforce partner with experience in scalable org design can accelerate the process and help avoid common pitfalls.
