Role hierarchy in Salesforce is a structured framework that defines the levels of data visibility and record access across users in an organization. Think of it as an organizational chart built directly into Salesforce one that controls not just who Reports to whom, but which records each person can see and work with.
Every Salesforce org maintains a role hierarchy. Roles sit within the broader Salesforce data security model alongside Organization-Wide Defaults (OWD), Sharing Rules, Profiles, and Permission Sets. While OWD sets the most restrictive baseline access, role hierarchy is the mechanism that opens up access as you move up the organizational ladder.
Key Definition: A role hierarchy in Salesforce lets users at higher role levels automatically view, edit, and report on all data owned by users below them in the hierarchy — regardless of the org-wide default settings.
An important distinction: role hierarchies do not have to mirror your org chart exactly. Each role in the hierarchy should simply represent a required level of data access, not necessarily a reporting line. A Regional Manager role, for instance, grants visibility into all records owned by Sales Reps beneath it — whether those reps report to the manager directly or not.
Why Role Hierarchy Matters for Salesforce Admins
Understanding role hierarchy in Salesforce is a core admin skill — and a recurring topic on the Salesforce Administrator certification exam. Getting it wrong leads to two common failures: users seeing data they shouldn’t (overexposure), or managers being locked out of data they need (under-access). The role hierarchy is your primary lever for solving both problems at scale.
2. How Role Hierarchy Controls Data Access
Role hierarchy works hand in hand with your org’s sharing model. Here is the fundamental principle:
A user assigned to a role can always see, edit, and report on records owned by users in roles below them in the hierarchy — as long as the “Grant Access Using Hierarchies” setting is enabled.
This means a VP of Sales automatically inherits visibility into everything owned by their Regional Managers, who in turn inherit visibility over their Sales Reps. The flow of access is always upward — higher roles gain access to lower roles’ records, never the reverse (unless sharing rules or manual sharing are applied separately).
Standard Objects
For Standard Objects (Accounts, Contacts, Opportunities, etc.), the “Grant Access Using Hierarchies” option is permanently enabled and cannot be turned off.
Custom Objects
For Custom objects, this setting can be disabled. When disabled, only the record owner and users with org-wide access can view the record — hierarchy is bypassed entirely.
System Permissions
Users with “View All Data” or “Modify All Data” system permissions bypass the hierarchy altogether — they can access all records regardless of role.
Role Hierarchy vs. Org-Wide Defaults
OWD sets the floor for record access. Role hierarchy builds on top of it. For example, if your OWD for Opportunities is set to Private, only the record owner can see it by default. But if a user in a higher role needs access, the role hierarchy kicks in and grants it automatically — no manual sharing required.
3. Role Hierarchy Structure (Diagram)
Below is a typical example of role hierarchy in Salesforce for a sales organization. The access flows upward: each role sees everything owned by roles beneath it.
Key takeaway: A Sales Rep can only see records they own (if OWD is Private). Their Regional Manager sees everything the reps own. The VP of Sales sees everything the Regional Manager and team own. The CEO sees everything.
4. How to Set Up Role Hierarchy — Step by Step
Before you create roles in Salesforce, sketch your organization’s structure on paper first. Identify each unique level of data access required — these become your roles. Then follow these steps:
- Log in to Salesforce and click the gear icon (âš™) in the top-right corner to navigate to Setup.
- In the Quick Find box, type “Roles” and select Roles from the results.
- On the Roles page, click “Set Up Roles” to open the role hierarchy tree.
- Click “Expand All” to view the full hierarchy at a glance.
- To add a new role, click “Add Role” under the appropriate parent role in the tree.
- Enter the Role Name, select the Reports To (parent) role, and fill in the description.
- Under Contact Access, configure whether users in this role can access contacts of accounts they do not own.
- Click Save. Repeat to build out the complete hierarchy.
Pro Tip: After creating roles, assign users by navigating to Setup → Users → Users, editing a user record, and selecting the appropriate role from the “Role” field. A user not assigned to any role cannot take advantage of hierarchy-based sharing.
Assigning Users to Roles
You can assign users to a role from two places: from within the Role detail page (click “Assign Users to Role”) or from the User detail page itself. The second approach is more common when onboarding a new team member. Always confirm that a new user is assigned to the correct role before they begin working — access issues are much harder to diagnose after records have been created.
5. Grant Access Using Hierarchies
The “Grant Access Using Hierarchies“ checkbox is a per-object setting that controls whether role-based upward visibility applies. You can find and manage this setting by navigating to Setup → Sharing Settings and scrolling to the object-level sharing settings table.
Important Note: For standard objects, this checkbox is always checked and greyed out — you cannot disable it. For custom objects, the checkbox is editable. Unchecking it means the role hierarchy will NOT grant access upward for that object. Only the record owner and users covered by OWD or sharing rules will have access.
When should you disable this for a custom object? A common scenario is a confidential HR or compensation object where even managers should not automatically see their employees’ records. Disabling hierarchy access and relying instead on manual sharing or permission sets gives you tighter control.
6. Role Hierarchy vs. Profiles vs. Permission Sets
One of the most common points of confusion for new Salesforce admins is understanding how role hierarchy fits alongside profiles and permission sets. They all form part of data security, but they operate at different levels:
| Feature | Controls | Affects OWD? | Record-Level? | Object-Level? |
|---|---|---|---|---|
| Role Hierarchy | Which records a user can see based on their position | Opens access | Yes | No |
| Profiles | Object-level CRUD permissions (Read, Create, Edit, Delete) | No | No | Yes |
| Permission Sets | Additional permissions on top of a profile | No | No | Yes |
| OWD | Baseline access for all users to all records | Is the baseline | Yes | No |
| Sharing Rules | Exceptions to OWD for specific groups or roles | Opens access | Yes | No |
The Salesforce security model is layered: OWD sets the restrictive baseline, role hierarchy opens access upward, and sharing rules handle exceptions. Profiles define what actions a user can perform on objects, while permission sets extend those capabilities. A user must satisfy all layers simultaneously to access a record.
7. Best Practices
A poorly designed role hierarchy creates headaches that grow exponentially with your organization. Follow these best practices from the start:
Keep it Simple & Scalable
Design for data access levels, not org chart politics. A hierarchy with 3–4 levels is nearly always sufficient. Overly deep hierarchies cause performance and maintenance issues.
Plan Before You Build
Map out the structure on paper first. Identify every unique data access requirement before creating a single role in Salesforce.
Align with Business Function
Base roles on business functions and access needs, not individual people. Roles should survive headcount changes — people leave, functions remain.
Apply Least Privilege
Users should only see what they need. Complement role hierarchy with profiles and permission sets to ensure no one has excessive data access.
Audit Regularly
Organizations evolve. Review role assignments quarterly to ensure they reflect current team structures and data access requirements.
Use Public Groups for Lateral Sharing
If two teams need to share data but don’t fall in the same hierarchy path, use Public Groups + Sharing Rules instead of forcing an artificial hierarchical relationship.
Leverage Delegated Administration
For large organizations, allow departmental administrators to manage user roles within their teams while maintaining overall control at a higher level.
8. Common Mistakes & How to Fix Them
1. Overexposing Data at the Top
Because higher roles inherit access to all records below them, a broad executive role can inadvertently see highly sensitive data. The fix is to use field-level security to hide specific sensitive fields, and to disable “Grant Access Using Hierarchies” on confidential custom objects where upward visibility is inappropriate.
2. Building the Hierarchy to Mirror the Org Chart
This is the most common design mistake. The Salesforce role hierarchy should reflect data access needs, not reporting lines. A support manager and a sales manager may share the same level of data access without either needing visibility into the other’s team records.
3. Assigning Users to the Wrong Role
Incorrect role assignments cause either overexposure or inaccessible records. Establish a formal process for role assignment during user onboarding, and review it whenever a user changes departments or responsibilities.
4. Confusing Roles with Profiles
A profile controls what a user can do (create, edit, delete objects). A role controls what records they can see. Both are necessary, and they complement each other. Granting a user an admin profile but a low-level role means they can edit any record their profile permits — but they may not be able to find records they don’t own.
5. Ignoring Performance Impact of Complex Hierarchies
Very deep or wide role hierarchies can slow down record sharing recalculations, especially in large orgs. Salesforce recommends keeping the hierarchy as flat as possible — generally no more than 10 levels deep — and avoiding unnecessary branching.
9. Frequently Asked Questions
Does role hierarchy override org-wide defaults (OWD)?
No — role hierarchy extends OWD. OWD sets the most restrictive baseline for all users. Role hierarchy only opens access upward from that baseline; it cannot restrict access below what OWD already permits.
Can a user belong to more than one role?
No. Each Salesforce user can be assigned to exactly one role at a time. If you need a user to have access across multiple branches of the hierarchy, use sharing rules or manual sharing to extend their access.
What happens if a user has no role assigned?
A user without a role will only see records they own (or records shared with them via OWD, sharing rules, or manual sharing). They receive no hierarchy-based access, and their records will not be visible to managers via the role hierarchy.
Does role hierarchy affect Chatter visibility?
Role hierarchy affects record-level access in Chatter feeds related to records. However, Chatter profile visibility and direct messaging are governed separately by Chatter settings, not role hierarchy.
Is role hierarchy important for the Salesforce Admin certification exam?
Absolutely. Role hierarchy is a key component of the Data Security topic, which is consistently one of the most-tested areas on the Salesforce Certified Administrator exam. Expect questions about when hierarchy grants access, how it interacts with OWD, and the “Grant Access Using Hierarchies” setting for custom objects.
Can role hierarchy be used with Salesforce Experience Cloud?
Yes, but with some nuance. External users (community users) have their own role hierarchy separate from internal users. Portal roles exist beneath your internal hierarchy, and record sharing for external users is handled through sharing sets and share groups rather than the standard internal role hierarchy.
10. Conclusion
Role hierarchy in Salesforce is one of the most powerful and foundational tools in a Salesforce Admin’s toolkit. When designed thoughtfully, it ensures that the right people have access to the right data — automatically and at scale — without requiring manual sharing for every record.
The key principles to take away: role hierarchy controls record-level visibility (not object-level permissions), it always flows upward, and it should be designed around data access needs rather than organizational politics. Pair it with a well-configured OWD, thoughtful sharing rules, and appropriate profiles, and you’ll have a data security model that scales gracefully as your organization grows.
Whether you’re preparing for the Salesforce Admin certification, troubleshooting an access issue, or designing a new org from scratch — a solid understanding of role hierarchy in Salesforce puts you miles ahead.
Ready to Master Salesforce Admin?
If this guide helped you understand role hierarchy in Salesforce, you’ll love what’s waiting inside the full Salesforce Admin Certification Course at MyTutorialRack.
The course covers every exam topic in depth — role hierarchy, OWD, sharing rules, profiles, permission sets, automation, and much more — with hands-on exercises and real-world scenarios designed to get you certified and job-ready.
- Certification-aligned curriculum
- Hands-on labs & practice exercises
- Expert instructor support
- Lifetime access to all content
