Role Hierarchy and Grant Access Using Hierarchies

1. Why This Topic Matters

The Role Hierarchy is one of the core pillars of the Salesforce sharing model, sitting directly on top of Organization-Wide Defaults (OWD). Almost every record-access scenario on the Advanced Administrator exam depends on understanding how access flows upward through roles and when that flow can be switched off using the Grant Access Using Hierarchies setting. The Advanced Security and Access section is one of the heaviest-weighted areas of the exam, and the role hierarchy is tested in combination with OWD, sharing rules, manual sharing, teams, View All/Modify All permissions, and Apex managed sharing. If you misunderstand how hierarchy access works, you will miss not only direct questions but also multi-layer scenario questions where the hierarchy is just one piece of the puzzle. In real-world terms, this topic is about ensuring managers can see their team's data while keeping sensitive data (compensation, HR, legal, confidential projects) locked down even from people higher in the organization.

2. What Is the Role Hierarchy?

The Role Hierarchy is a tree structure of roles in Setup (Setup > Roles) that controls the vertical flow of record access. It is not a profile, it does not grant object or field permissions, and it does not need to mirror your HR org chart. Its sole purpose is to extend record-level access upward.

Key characteristics:
• A user can be assigned to only one role (or no role at all).
• Users in a higher role automatically gain access to records owned by users in roles below them, and records shared with users below them (via sharing rules, manual sharing, teams, or Apex sharing).
• Access flows upward only. Peers in the same role do not see each other's records through the hierarchy, and subordinates never gain access to their manager's records through it.
• The hierarchy grants at least Read and typically Read/Edit access depending on OWD and the access the subordinate holds. If a subordinate owns a record, the manager gets full owner-like access (Read, Edit, and in most cases the ability to Transfer and Share). If the subordinate only has Read access through a share, the manager also receives only Read.
• A user with no role has no manager in the hierarchy, so no one gains access to their records via the hierarchy. Their records can still be shared via sharing rules, groups, or manual sharing.
• The default limit is 500 roles per org (can be raised by Salesforce Support), and best practice is to keep the hierarchy shallow and purpose-built for data visibility rather than copying the entire org chart.
• Changing a user's role or moving a role in the tree triggers sharing recalculation, which can be deferred using Defer Sharing Calculations in large orgs.

3. What Is Grant Access Using Hierarchies?

Grant Access Using Hierarchies is a checkbox found in Setup > Sharing Settings, within the Organization-Wide Defaults table, with one checkbox per object. It determines whether the role hierarchy is used to extend access for that specific object.

Critical rules you must memorize:
• It is enabled by default for every object.
• It is always enabled and cannot be disabled for standard objects (Account, Contact, Opportunity, Case, Lead, etc.). The checkbox appears greyed out.
• It can be disabled only for custom objects.
• The setting is irrelevant when the OWD is Public Read/Write, because everyone already has full access. It only has practical effect when OWD is Private or Public Read Only (or Controlled by Parent in some contexts).
• When disabled, users above the record owner in the hierarchy do not automatically get access to records owned by or shared with their subordinates. This includes access that would otherwise roll up from sharing rules, manual shares, and Apex managed sharing.
• Disabling it does not affect users who have View All or Modify All object permissions, or View All Data / Modify All Data system permissions. These permissions bypass the sharing model entirely. System Administrators therefore still see everything.
• Disabling it does not prevent you from using sharing rules that target roles. You can still create a sharing rule granting access to the role Sales Manager or Roles and Internal Subordinates, but the subordinates option works through group membership, not through the automatic hierarchy roll-up.

4. How It Works: Step by Step

Step 1 – OWD sets the baseline. If the Position__c object has an OWD of Private, only the record owner (and those above them, if hierarchy access is enabled) can see each record.

Step 2 – Role Hierarchy opens access upward. With Grant Access Using Hierarchies enabled, a Regional Manager role above a Recruiter role can view, edit, and report on all Position__c records owned by Recruiters below them.

Step 3 – Shared access also rolls up. If a sharing rule gives Recruiters read access to Positions owned by the HR Team, the Regional Manager above those Recruiters also inherits that read access because it rolls up through the hierarchy.

Step 4 – Disabling the checkbox severs the vertical flow. If you uncheck Grant Access Using Hierarchies for Position__c, the Regional Manager loses access to Recruiter-owned Positions and to Positions shared with Recruiters. The Regional Manager now sees only records they own, records explicitly shared with them (directly, via group, or via their own role being named in a rule), or everything if they hold View All.

Step 5 – Lateral access requires other tools. Because the hierarchy never grants peer-to-peer access, two Recruiters in the same role who need to collaborate require a sharing rule (for example, owner-based rule: records owned by Role Recruiter shared with Role Recruiter), a public group, Account/Opportunity/Case Teams, or manual sharing.

5. Role Settings That Interact With the Hierarchy

When you edit a role, you may see additional settings that only appear when the related OWD is Private:
• Contact Access – controls whether users in the role can view or edit Contacts associated with Accounts they own (when Contact OWD is Private).
• Opportunity Access – controls access to Opportunities on Accounts the user owns.
• Case Access – controls access to Cases on Accounts the user owns.
These are per-role settings and are often confused with Grant Access Using Hierarchies on the exam. They govern access to related child records on owned accounts, not upward access through the hierarchy.

6. Related Concepts You Must Distinguish

• Profiles / Permission Sets: grant object CRUD and field-level security. The hierarchy cannot override a missing Read permission. A manager with no Read on Position__c sees nothing regardless of hierarchy.
• Sharing Rules: lateral or cross-hierarchy extensions; can grant to Roles, Roles and Internal Subordinates, Roles, Internal and Portal Subordinates, Public Groups, Territories, or Queues. They can only open access, never restrict it.
• Manual Sharing: record-by-record, one-off access granted by owner, those above the owner in the hierarchy (if enabled), or administrators.
• Teams (Account, Opportunity, Case Teams): collaborative access for specific records.
• Territory Management: an alternative/addition to the role hierarchy for Accounts and related records when a single tree does not fit the business (for example, matrix organizations).
• Partner Community users: have roles (up to three per partner account) that sit beneath the account owner's role; the account owner and those above gain access to partner-owned records via the hierarchy. Customer Community users (non-partner licenses) do not have roles, so sharing to them relies on Sharing Sets and Share Groups.
• Collaborative Forecasts: use a forecast hierarchy derived from the role hierarchy, with forecast managers assigned per role.
• Reports and Dashboards: role hierarchy enables report filters such as My team's records and supports hierarchy drill-down on opportunity reports.

7. Common Use Cases for Disabling Grant Access Using Hierarchies

• Compensation or Bonus custom objects where an employee's direct manager should not see peers' or the CEO should not automatically see everyone's data.
• HR cases, grievance or whistle-blower records stored in a custom object.
• Confidential legal matters or M&A deal records.
• Any custom object where visibility should be strictly need-to-know and controlled through explicit sharing rules or manual shares rather than organizational seniority.

8. Exam Tips: Answering Questions on Role Hierarchy and Grant Access Using Hierarchies

Tip 1 – Check the object type first. If the scenario says managers must not see subordinates' records and the object is a standard object (Account, Opportunity, Case, Contact, Lead), you cannot disable Grant Access Using Hierarchies. The correct approach would involve moving the data to a custom object, using restrictive OWD plus careful role design, or accepting that managers will see the data. If it is a custom object, disabling the checkbox is the textbook answer.

Tip 2 – Check the OWD. If OWD is Public Read/Write, the hierarchy and the checkbox change nothing. Eliminate answers that rely on the hierarchy in a Public Read/Write scenario. Hierarchy questions almost always involve Private or Public Read Only.

Tip 3 – Remember access flows UP only. Any requirement for peers, same-role colleagues, or cross-department visibility is never solved by the role hierarchy. Look for sharing rules, public groups, teams, or manual sharing in the answer choices.

Tip 4 – Know what still bypasses the setting. View All, Modify All, View All Data, Modify All Data, and the System Administrator profile are unaffected by disabling Grant Access Using Hierarchies. If a question asks why an executive can still see records after the checkbox was unchecked, the answer is almost certainly a View All / Modify All permission.

Tip 5 – Shared records roll up too. Many candidates believe the hierarchy only extends access to owned records. It also extends access to records shared with subordinates through sharing rules, manual shares, teams, and Apex sharing. Disabling the checkbox cuts off all of these roll-ups for that object.

Tip 6 – Hierarchy does not override profiles. If a manager lacks object Read permission or field-level visibility, the hierarchy will not help. When a question says a manager cannot see a field or an object at all, think Profile/Permission Set, not hierarchy.

Tip 7 – Users with no role are dead ends. Records owned by a user without a role cannot be reached via the hierarchy by anyone. If the scenario involves integration users or new users not yet assigned a role, this is often the cause of unexpected invisibility.

Tip 8 – Do not confuse the checkbox with Role-level Contact/Opportunity/Case Access settings. Those settings control child-record access on owned Accounts and appear only when the child OWD is Private. Grant Access Using Hierarchies controls upward access per object in Sharing Settings.

Tip 9 – Watch for the word subordinates in sharing rule options. Roles and Internal Subordinates and Roles, Internal and Portal Subordinates are sharing rule targets built from the hierarchy but implemented through groups. They continue to work even if Grant Access Using Hierarchies is unchecked for a custom object, because they are explicit shares, not automatic roll-up.

Tip 10 – Sharing recalculation and performance. If a question mentions a large org, mass role changes, or performance concerns, remember Defer Sharing Calculations and the recommendation to keep the hierarchy shallow and avoid unnecessary roles.

Tip 11 – Least privilege wins. When two answers both technically work, the exam generally prefers the one that grants the minimum access needed and uses declarative tools in this order: OWD, Role Hierarchy, Sharing Rules, Teams, Manual Sharing, with Apex sharing as a last resort.

9. Practice Scenarios

Scenario A: Compensation__c has an OWD of Private. HR Specialists own the records. The VP of Sales, who is above HR in the role hierarchy, should not see any compensation records. What should the administrator do?
Answer: Uncheck Grant Access Using Hierarchies for Compensation__c in Sharing Settings. Verify the VP does not have View All or Modify All on the object.

Scenario B: Opportunity OWD is Private. Sales Managers need to see all opportunities owned by their reps, but the Finance role should not see any opportunities. Finance is in a separate branch of the hierarchy.
Answer: No action needed for the hierarchy itself; Sales Managers see rep records through the role hierarchy, and Finance, being in a different branch and not above Sales, has no access. You cannot disable Grant Access Using Hierarchies on Opportunity because it is a standard object, but the branch structure already solves it.

Scenario C: Two Account Executives in the same role must see each other's Accounts (OWD Private). What is the simplest solution?
Answer: An owner-based sharing rule sharing Accounts owned by the Account Executive role with the Account Executive role (or a public group containing them). The hierarchy cannot provide lateral access.

Scenario D: After disabling Grant Access Using Hierarchies on Project__c, the CFO can still see every project. Why?
Answer: The CFO's profile or a permission set grants View All on Project__c (or View All Data), which bypasses sharing.

Scenario E: A manager cannot see any records owned by a newly hired rep even though the manager's role is above the Sales Rep role.
Answer: The new rep most likely has not been assigned a role, so the hierarchy cannot route access upward. Assign the rep to the appropriate role.

10. Quick Reference Summary

• Role hierarchy = vertical, upward-only extension of record access built on top of OWD.
• One role per user; users with no role share with no one via hierarchy.
• Grant Access Using Hierarchies: in Sharing Settings, per object, on by default, locked on for standard objects, optional for custom objects.
• Disabling it removes manager roll-up of owned and shared records, but does not affect View All / Modify All / View All Data / Modify All Data users.
• Hierarchy never overrides profile CRUD or FLS, and never grants lateral access.
• Lateral or cross-branch needs = sharing rules, public groups, teams, manual sharing, or territories.
• For exam questions, always identify in order: object type (standard vs custom), OWD, direction of access needed (up, down, or lateral), and any bypass permissions in play.

Master these principles and you will be able to decode any sharing scenario on the Advanced Administrator exam that involves the role hierarchy, and you will be equipped to design secure, maintainable access models in a real Salesforce org.