Salesforce Admin Zero to Hero - Module 4: Roles & Role Hierarchy | SF Interview Pro

🏢 Salesforce Admin Zero to Hero — Module 4 of 25

Roles & Role Hierarchy

Module 3 mastered Profiles — what a user CAN DO. This module covers the other half of the equation: the Role Hierarchy, which determines what a user CAN SEE by their position in the reporting structure.

Module 4 of 25 · Phase 1: Org Setup & Security Foundations

🎯 What You Will Master in This Module

The Role Hierarchy is the single most misunderstood piece of Salesforce's security model for beginners — mostly because it looks like an org chart but does not behave exactly like one. Getting this right means understanding precisely what "vertical access" means and where it stops.

✓ What the Role Hierarchy actually grants — and the one critical exception

✓ Designing a Role Hierarchy that mirrors real reporting lines without over-complicating it

✓ Grant Access Using Hierarchies — the checkbox that controls whether hierarchy access even applies to a custom object

✓ Roles vs Reporting Structure — why they are related but not identical

✓ Portal Roles and how external users fit into (or bypass) the internal hierarchy

✓ Common hierarchy design mistakes that cause data visibility problems months later

✓ How Role Hierarchy works alongside Profiles and sets up everything Module 5 (Sharing Model) builds on

📋 In This Module

1What the Role Hierarchy Actually Grants 2Designing a Role Hierarchy 3Grant Access Using Hierarchies 4Roles vs Reporting Structure 5Portal Roles & External Users 6Common Hierarchy Design Mistakes 7Role Hierarchy + Profile, Working Together QInterview Questions (6)

Concept 1 of 7

What the Role Hierarchy Actually Grants

The Role Hierarchy grants vertical, automatic record access: any user sees their own records, plus every record owned by any user BELOW them in the hierarchy. This access flows strictly upward — a manager sees their reports' data, but a report never sees their manager's data purely from hierarchy position. This is one of four ways Salesforce grants record access, alongside Ownership, Sharing Rules, and Manual Sharing (Module 5).

⚡ Why This Matters

Role Hierarchy access is completely automatic — you do not build a single Sharing Rule for it to work. The moment you place a user at a certain position in the hierarchy, they instantly gain visibility into every record owned by everyone below them, across every object where hierarchy-based sharing applies. This is powerful, which is exactly why hierarchy design mistakes are so consequential.

Example Hierarchy: CEO | Sales Director / \ Sales Manager A Sales Manager B / \ \ Rep 1 Rep 2 Rep 3 Sales Manager A sees: their own records + Rep 1's + Rep 2's Sales Director sees: their own + Manager A's + Manager B's + Rep 1's + Rep 2's + Rep 3's Rep 1 sees: ONLY their own records (nobody reports to Rep 1) Rep 2 does NOT see Rep 1's records (they are peers, not in a reporting line)

🛠️ Hands-On: See Role Hierarchy Access in Action

1Setup → Quick Find → Roles → click Set Up Roles

2Click Add Role at the top level (usually under CEO) → Name it Sales Director → Save.

3Click on Sales Director → Add Role underneath it → Name it Sales Manager → Save.

4Click on Sales Manager → Add Role underneath it → Name it Sales Rep → Save. You now have a 3-level chain: Sales Director → Sales Manager → Sales Rep.

5Assign your Test User (from Module 2) the Sales Rep role. Assign your own user the Sales Director role.

6Create an Opportunity owned by your Test User. Confirm you (as Sales Director) can see it in a report or list view filtered to "All Opportunities" — this is hierarchy access working automatically, with zero Sharing Rules involved.

⚠️ Critical Gotcha — Hierarchy Access Never Flows Downward or Sideways

A very common beginner assumption is that Role Hierarchy creates some form of team-wide visibility. It does not. Two Sales Reps under the same Sales Manager CANNOT see each other's records through the hierarchy — they are peers, not in a reporting line with each other. If peer-level visibility is a genuine business need, that requires a Sharing Rule (Module 5), not a hierarchy restructure.

Concept 2 of 7

Designing a Role Hierarchy That Actually Works

A Role Hierarchy should represent the DATA VISIBILITY structure your business genuinely needs — not necessarily a perfect mirror of your company's HR org chart. These two things often look similar but are not the same thing, and conflating them is where most hierarchy design problems begin.

⚡ Why This Matters

An HR org chart might have 200 unique titles across a company. A Role Hierarchy with 200 unique Roles is unmanageable and mostly unnecessary — most of those title distinctions do not correspond to any actual difference in what data someone needs to see. Good hierarchy design groups people by DATA ACCESS NEED, not by job title precision.

Design Principle	Why It Matters
Model data visibility, not org charts	Two different job titles with identical data access needs can share one Role
Keep the hierarchy shallow where possible	Deep hierarchies (8+ levels) slow down internal sharing recalculation and are harder to reason about
One Role can have many Users	A Role is a position in the structure, not a 1-to-1 mapping to a single person
Design by territory/region/team when relevant	Sales organizations often need hierarchy branches split by geography, not just management layer

🛠️ Hands-On: Extend Your Hierarchy By Territory

1Setup → Roles → click on Sales Director → Add Role → create Sales Manager - West as a sibling to your existing Sales Manager role.

2Under Sales Manager - West, add Sales Rep - West.

3Go back to Set Up Roles → view the full tree. Notice you now have two parallel branches under Sales Director — West and (your original, rename it) East — each with their own Manager and Rep layer.

4This branch structure means a West Manager sees only West Rep data through the hierarchy, while the Sales Director above both branches sees everyone — exactly matching how a real regional sales org needs its data segmented.

💡 Fewer, Broader Roles Beat Many Narrow Ones

Just like the Profile design principle from Module 3, the same logic applies to Roles: aim for a lean, intentional hierarchy rather than one Role per exact job title. If two positions have identical data visibility needs, they can share a Role even if their job titles differ. Save fine-grained individual exceptions for Manual Sharing or Sharing Rules, not for creating another Role.

Concept 3 of 7

Grant Access Using Hierarchies — The Checkbox That Controls Everything

For every custom object, Salesforce shows a checkbox called Grant Access Using Hierarchies when you set its Organization-Wide Default (OWD, covered fully in Module 5). This single checkbox determines whether Role Hierarchy access applies to that object AT ALL. Standard objects always respect the hierarchy and cannot turn this off — but custom objects genuinely can.

⚡ Why This Matters

This is one of the most commonly missed settings in real orgs. An Admin may build a perfect Role Hierarchy, then wonder why a Sales Director cannot see a custom object's records owned by their team — the answer is almost always that Grant Access Using Hierarchies was left unchecked for that specific custom object.

Standard Objects (Account, Opportunity, Case, Contact, Lead, etc.): Grant Access Using Hierarchies is ALWAYS ON Cannot be disabled — hierarchy access is guaranteed Custom Objects (any object you build, suffixed __c): Grant Access Using Hierarchies is a CHECKBOX you control Checked (default) → Role Hierarchy applies normally Unchecked → Hierarchy is IGNORED for this object entirely Only Ownership + Sharing Rules + Manual Sharing apply

🛠️ Hands-On: Find and Toggle This Setting

1Setup → Quick Find → Sharing Settings → click it

2Scroll to Organization-Wide Defaults → find any custom object in the list (if you do not have one yet, this exercise will make more sense after Module 8 — Custom Objects, and is worth revisiting then).

3Click Edit next to the custom object → look for the checkbox Grant Access Using Hierarchies next to its OWD setting.

4Note it is checked by default when the object is created. If a client or manager ever asks "why can't my managers see this custom object's records even though the hierarchy is set up correctly," this is the very first thing to check.

⚠️ Common Gotcha — This Setting Cannot Be Changed on Standard Objects

Do not go looking for this checkbox on Account, Opportunity, or Case — it does not appear as an editable option for standard objects because hierarchy access is mandatory and permanent for them. This checkbox only appears for custom objects, which is a frequent point of confusion during Admin certification prep and real troubleshooting alike.

Concept 4 of 7

Roles vs Reporting Structure — Related, But Not Identical

It is tempting to assume the Role Hierarchy IS your company's reporting structure. In practice, they are related but distinct: the Role Hierarchy is a data-visibility structure that should be INFORMED by reporting lines, but does not need to match them field-for-field, and critically, a User's Manager field (used for approval routing) is entirely separate from their Role.

⚡ Why This Matters

Confusing these two causes real problems: Admins sometimes assume changing someone's Manager field on their User record will change their data visibility, or assume restructuring the Role Hierarchy will automatically fix an Approval Process routing issue. Neither is true — they are configured completely independently, even though both often mirror the same real-world management chain.

	Role (Role Hierarchy)	Manager Field (on User record)
Controls	Vertical data visibility across the org	Approval routing, "my team" filters in some reports, org chart display
Where it's set	Roles field on the User record, pointing into the Role Hierarchy tree	Manager field on the User record, pointing to another specific User
Independent?	Yes — changing one does not change the other	Yes — a user's Manager and their Role position can be completely unrelated

🛠️ Hands-On: See Both Fields Side by Side

1Setup → Users → open your Test User → click Edit

2Locate the Role field — this is what you configured in Concepts 1 and 2, controlling hierarchy-based data visibility.

3Now locate the separate Manager field, usually near the top of the user detail fields — set it to your own user.

4Save. Notice both fields can now be independently verified: the Role field still governs hierarchy-based visibility, while the Manager field is what an Approval Process would reference if the approval step was configured as "Manager."

⚠️ Common Gotcha — Assuming Manager Field Grants Data Access

Setting a user's Manager field does NOT grant that manager any additional record visibility. Only the Role Hierarchy grants automatic, ownership-based vertical visibility. If a manager cannot see their team's records, check the Role Hierarchy position first — the Manager field is very unlikely to be the actual cause.

Concept 5 of 7

Portal Roles & External Users

When external users — customers or partners accessing an Experience Cloud site — are given login access, Salesforce automatically creates special Portal Roles for them, distinct from your internal Role Hierarchy. Understanding how these fit in (and how they are deliberately restricted) matters for any org with external-facing access.

⚡ Why This Matters

External users should never accidentally gain visibility into internal-only data through hierarchy misconfiguration. Salesforce's Portal Role design is deliberately restrictive by default specifically to prevent this — understanding why helps you avoid accidentally loosening it.

Internal Role Hierarchy (your employees): CEO → Sales Director → Sales Manager → Sales Rep Full vertical visibility as covered in Concept 1 External Portal Roles (customers/partners via Experience Cloud): Automatically created PER ACCOUNT when portal access is enabled Example: "Ami Polymer Customer Portal User", "Ami Polymer Customer Portal Manager" Strictly scoped to that ONE external Account's own data by default Cannot see other external Accounts' data, and cannot see internal-only records unless deliberately shared

🛠️ Hands-On: Observe Portal Role Behavior (Conceptual)

1Setup → Quick Find → Digital Experiences → All Sites — note whether any Experience Cloud site exists in your Dev Org (most fresh Developer Orgs do not have one by default).

2If you do have a site, or once you build one in a later module, note that enabling portal access on a specific Contact/Account automatically generates Portal Roles scoped to that Account — this happens without you manually building anything in Set Up Roles.

3Setup → Quick Find → Roles → Set Up Roles — if portal users exist, you will see their roles nested separately from your internal hierarchy, clearly labeled as portal-related.

4Key takeaway even without a live site to click through: never manually reassign a portal user's role into your internal hierarchy — this would be a serious data exposure risk, potentially giving an external customer visibility into unrelated internal records.

💡 Portal Roles Are Covered Fully Later

Experience Cloud, Sites, and the full external-sharing model are broad enough topics to warrant their own dedicated treatment later in this course. This concept is intentionally a conceptual introduction so the Role Hierarchy picture is complete — you now know internal Roles and external Portal Roles are structurally separate systems, which is the key fact worth retaining from this section.

Concept 6 of 7

Common Hierarchy Design Mistakes

Certain Role Hierarchy design mistakes show up repeatedly across real orgs, usually because they seemed reasonable at the time and only caused visible problems months later once the org had grown. Recognizing these patterns in advance is far cheaper than untangling them after the fact.

⚡ Why This Matters

Restructuring a live Role Hierarchy in a production org with real data and real sharing dependencies is a genuinely risky operation — it can trigger a lengthy sharing recalculation process and unexpectedly change data visibility for many users at once. Getting the design right early avoids ever needing to do this under pressure.

Mistake	Consequence
Mirroring the full HR org chart exactly	Unmanageably deep hierarchy with Roles that don't correspond to any real data visibility difference
One Role per individual person	Hierarchy becomes a duplicate of the User list rather than a reusable structure
Flat hierarchy (everyone at one level)	No vertical visibility at all — managers cannot see their team's data automatically
Forgetting Grant Access Using Hierarchies on custom objects	Hierarchy looks correct but a specific custom object silently ignores it
Restructuring without planning sharing recalculation	Temporary but very real performance impact and unexpected access changes org-wide

🛠️ Hands-On: Audit Your Own Hierarchy Against These Patterns

1Setup → Roles → Set Up Roles → view your current tree from Concepts 1 and 2.

2Count the depth — how many levels deep is your deepest branch? For a learning exercise 3-4 levels is fine; in a real org, question anything beyond 5-6 levels.

3Ask: does every Role represent a genuinely different data visibility need, or did any get created just to match a job title? Note any you would consolidate in a real design review.

4This exercise — reviewing an existing hierarchy against these five mistakes — is a genuinely useful audit to run periodically in any real org you administer.

⚠️ Critical Gotcha — Hierarchy Changes Trigger Sharing Recalculation

Moving a Role to a different position in the hierarchy, or reassigning many users to different Roles at once, causes Salesforce to recalculate sharing access for every affected record — which can take significant time in a large org and briefly impact performance. Always make hierarchy structure changes during low-traffic periods and communicate the change in advance, exactly like the Module 1 guidance on foundational settings.

Concept 7 of 7

Role Hierarchy + Profile, Working Together

Module 3 and Module 4 together form the two-part answer to "what can this user do and see." Neither one alone tells the complete story — a user's actual experience in the org is always the intersection of their Profile's permissions AND their Role's position in the hierarchy, evaluated together for every single record.

⚡ Why This Matters

This is the moment where Modules 1 through 4 fully connect. Every future access-related troubleshooting scenario in this course — and in your real job — starts with the same two questions: what does this Profile allow, and what does this Role's hierarchy position grant. Module 5 adds the third and fourth pieces: Sharing Rules and Manual Sharing.

Full picture for one specific record — can User X access it? 1. Does User X's Profile grant Object-Level Read on this object at all? NO → Access denied, full stop. Nothing else matters. YES → continue to step 2 2. Does User X own this record, OR are they above the owner in the Role Hierarchy (with Grant Access Using Hierarchies ON)? YES → Access granted (subject to Field-Level Security per field) NO → continue to Module 5: check Sharing Rules and Manual Sharing 3. (Module 5) Does any Sharing Rule or Manual Share grant access? YES → Access granted NO → User X cannot see this record

🛠️ Hands-On: Trace the Full Decision Path for a Real Record

1Open the Opportunity record you created in Concept 1, owned by your Test User (Sales Rep).

2Click the Sharing button on the record (usually under the dropdown menu, top right) — this shows you the EXACT list of who has access and why.

3You should see your own user listed with a reason like "Role: Sales Director" — this is Salesforce directly confirming the Role Hierarchy is the reason for your access, exactly matching the decision path above.

4This Sharing button is, and will remain, your single fastest diagnostic tool for any "why can/can't this user see this record" question for the rest of your Admin career.

⚠️ Module Wrap-Up — What Comes Next

You now have two of the four record-access mechanisms fully mastered: Profile (permissions) and Role Hierarchy (vertical visibility). Module 5 completes the picture with the full Sharing Model — Organization-Wide Defaults, Sharing Rules, and Manual Sharing — covering every scenario where Ownership and Hierarchy alone are not enough, like peer-to-peer visibility or cross-team collaboration on specific records.

💬 Module 4 Interview Questions (6)

Q1Two Sales Reps report to the same Sales Manager. Rep A says they cannot see Rep B's Opportunities. Is this a bug?

This is expected, correct behavior, not a bug. The Role Hierarchy only grants vertical visibility — a user sees their own records plus records owned by anyone below them in the hierarchy. Rep A and Rep B are peers at the same level under the same manager, meaning neither is above the other in the hierarchy, so hierarchy-based access does not apply between them at all. Their Sales Manager, being above both of them in the hierarchy, would see both of their records, but the two Reps will never see each other's data through the Role Hierarchy alone. If peer-to-peer visibility is a genuine business requirement, it needs to be solved with a Sharing Rule based on Role or Public Group membership, which is covered in Module 5, not by any restructuring of the Role Hierarchy itself.

"Not a bug — Role Hierarchy only grants vertical (upward) visibility, so peers under the same manager never see each other's records through hierarchy alone. Peer-to-peer visibility requires a Sharing Rule, which is a completely separate mechanism from restructuring the hierarchy."

Q2A Sales Director cannot see their team's records on a custom object, even though the Role Hierarchy looks correctly configured. What is the most likely cause?

The most likely cause is that the Grant Access Using Hierarchies checkbox is unchecked for that specific custom object's Organization-Wide Default setting. Unlike standard objects, where hierarchy access is mandatory and cannot be disabled, custom objects have this as an explicit, controllable checkbox, and if it is unchecked, the Role Hierarchy is completely ignored for that object regardless of how correctly the hierarchy itself is structured. The fix is to go to Setup, Sharing Settings, find the custom object's OWD row, click Edit, and check the Grant Access Using Hierarchies box, which will restore hierarchy-based visibility for that object going forward.

"Almost certainly the Grant Access Using Hierarchies checkbox is unchecked on that custom object's OWD setting — unlike standard objects where hierarchy access is mandatory, custom objects let you disable it, silently breaking hierarchy visibility for that one object only."

Q3What is the practical difference between a user's Role and their Manager field, and why does confusing them cause real problems?

A user's Role determines their position in the Role Hierarchy, which controls automatic, ownership-based vertical data visibility — who can see records owned by whom. The Manager field is a completely separate field on the User record, primarily used for Approval Process routing and certain "my team" style report filters, and has no effect whatsoever on record visibility. Confusing them causes real problems in two directions: an Admin might change someone's Manager field expecting their data visibility to change, and be confused when it does not, or an Admin might restructure the Role Hierarchy expecting an Approval Process routing issue to resolve, when the Approval Process was actually referencing the separate Manager field the whole time. Both fields often mirror the same real-world reporting line, which is exactly why they get conflated, even though they are configured and function completely independently.

"Role controls data visibility through the hierarchy; Manager field controls approval routing and has zero effect on visibility — they're independent fields that happen to often mirror the same real reporting line, which is exactly why they get confused, causing wasted troubleshooting time on the wrong field."

Q4A company is designing its Role Hierarchy and wants to mirror their 150-title HR org chart exactly, with one Role per job title. What would you advise, and why?

I would advise against a 1-to-1 mapping between job titles and Roles, and instead recommend designing the hierarchy around actual data visibility needs rather than HR title precision. Many of those 150 titles likely correspond to identical or near-identical data access requirements, meaning a much smaller number of Roles, perhaps 15 to 25, can represent the same functional visibility structure the business actually needs. A hierarchy with 150 unique Roles becomes very difficult to maintain, audit, and reason about over time, and every additional Role adds complexity to sharing recalculation without necessarily adding any genuine visibility distinction. The recommended approach is the same principle used for Profile design in Module 3: keep the structure lean and intentional, and use Sharing Rules or Manual Sharing for any narrower exceptions that a broader Role structure does not naturally cover.

"Advise against a 1-to-1 title mapping — design the hierarchy around actual data visibility needs, which usually collapses 150 titles into far fewer genuinely distinct Roles, keeping the hierarchy lean and maintainable while using Sharing Rules for any narrower exceptions."

Q5Why are Portal Roles for Experience Cloud users kept structurally separate from the internal Role Hierarchy, and what risk does this design prevent?

Portal Roles are automatically generated per external Account when portal access is enabled, and are deliberately scoped tightly to that specific external Account's own data by default, structurally separate from the internal employee Role Hierarchy. This design specifically prevents external customers or partners from gaining unintended visibility into internal-only records or into other unrelated external Accounts' data, which could happen if external users were ever placed directly into the same hierarchy tree as internal employees. Since Role Hierarchy access flows automatically and can cascade broadly, keeping external portal access in a separate, tightly scoped structure is a deliberate security safeguard, and manually attempting to merge a portal user's role into the internal hierarchy would represent a serious and avoidable data exposure risk.

"Portal Roles are kept structurally separate and tightly scoped to prevent external users from ever gaining automatic visibility into internal-only records or other customers' data through the same broad hierarchy mechanics that apply internally — manually merging them into the internal hierarchy would be a serious security risk."

Q6Walk through the complete decision path Salesforce uses to determine whether a specific user can access a specific record, based on what you have learned through Module 4.

The first check is Object-Level Security on the user's Profile: if the Profile does not grant at least Read permission on that object, access is denied immediately regardless of anything else, since this is the first gate every access check passes through. If Object-Level access is granted, the second check is Ownership and Role Hierarchy: does the user own the record, or are they positioned above the record's owner in the Role Hierarchy, assuming Grant Access Using Hierarchies is enabled for that object. If either of those is true, access is granted, subject to Field-Level Security limiting which specific fields are visible. If neither Ownership nor Hierarchy grants access, the decision moves to a third and fourth check covered in Module 5: whether any Sharing Rule or Manual Share explicitly grants that user access to that specific record, which is the mechanism for cases like peer-to-peer visibility that Ownership and Hierarchy alone cannot solve.

"First check Object-Level Security on the Profile — no access if that fails. Then check Ownership and Role Hierarchy position — access granted if either applies. If not, Module 5's Sharing Rules and Manual Sharing are the final checks for cases like peer visibility that Ownership and Hierarchy alone cannot cover."

📝 Module 4 Recap — Roles & Role Hierarchy Mastered

✅ Role Hierarchy grants automatic, VERTICAL access only — up the tree, never down or sideways to peers

✅ Design Roles around data visibility needs, not a 1-to-1 mirror of the HR org chart — keep the structure lean

✅ Grant Access Using Hierarchies is mandatory-on for standard objects, but a real toggle on custom objects — check it first when hierarchy access seems broken on a custom object

✅ Role (data visibility) and Manager field (approval routing) are completely independent, even though they often mirror the same real reporting line

✅ Portal Roles for external Experience Cloud users are structurally separate from your internal hierarchy — never merge them

✅ Avoid the five common design mistakes: mirroring HR exactly, one Role per person, flat hierarchies, forgetting the custom object checkbox, and unplanned restructuring

✅ Full access decision path: Profile Object-Level Security first, then Ownership/Hierarchy, then Sharing Rules/Manual Sharing (Module 5) — use the record's Sharing button to see the real answer instantly

🎯 Module 4 Practical Checklist — Complete These in Your Org

1. Build a 3-level Role Hierarchy: Director → Manager → Rep, and assign your Test User and your own user to different levels.
2. Create an Opportunity owned by your Test User and confirm hierarchy-based visibility using the Sharing button on the record.
3. Add a second branch (e.g. West/East or a second Manager) and confirm peers under different branches still cannot see each other's data.
4. Set the Manager field on your Test User separately from their Role, and confirm both fields behave independently.
5. Note where the Grant Access Using Hierarchies checkbox lives in Sharing Settings, ready to use once you build your first custom object in Module 8.

Module 5 completes the full Sharing Model — Organization-Wide Defaults, Sharing Rules, and Manual Sharing — the two remaining pieces needed to answer any data visibility question completely.

← Module 3: Profiles Mastery Module 5: Sharing Model →

Test yourself on this topic

2,244 practice MCQs across 27 quizzes — 5 quizzes free, no signup

Open Practice Zone →

Written by

Rajnish Kumar

Salesforce Developer · Apex, LWC, Data Cloud & AI · Building SF Interview Pro

Connect on LinkedIn ↗