Design It for Access, Not as an Org Chart
Module 4 of 7 in the chapter Org-Wide Defaults, Ownership and the Role Hierarchy, chapter 6 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.
The question this module answers: How does the role hierarchy share records, and how do you design one that gives managers what they need without turning every change into a recalculation?
Back to the Runway demo. The object is Private. In module 3, the pilot became the owner of one runway and saw it. Now I log in as the manager. The manager owns nothing, and nobody shared anything by hand. But the manager sees the pilot’s runway. Why? Because the manager’s role is above the pilot’s role, and Grant Access Using Hierarchies is on. Log in as the director, one level higher, and the director sees it too.
That’s way 2, grant access using hierarchies. Ownership is the first key. The hierarchy copies that key up the branch.
What the hierarchy does
Section titled “What the hierarchy does”Salesforce’s rule: “Users at any role level can view, edit, and report on all data that’s owned by or shared with users below them in their role hierarchy” (Create a User Role (opens in a new tab), Salesforce Help, checked 2026-11-07). Two exceptions, on the same page: you can turn Grant Access Using Hierarchies off for a custom object, and a folder shared with a role is “visible only to users in that role, not to superior roles.”
Read that rule closely, because it says more than people think.
- “Owned by or shared with.” It isn’t only what your team owns. If a rule shares a record with someone below you, you get it too.
- Up, never across. The access climbs the branch to the top. It doesn’t go sideways. The pilot’s record doesn’t go to the other pilots, and it doesn’t go to a manager in the next branch. They’re siblings, and siblings don’t get access. Salesforce: “Peers within the same role don’t guarantee them access to each other’s data” (Platform Sharing Architecture (opens in a new tab), Salesforce Architects, checked 2026-11-07).
- The role, not the Manager field. People get confused here. The user record has a Manager field, and it has nothing to do with this. It’s the role, and who’s above that role.
- Regardless of the default. “The role hierarchy ensures that managers always have access to the same data as their employees, regardless of the organization-wide default settings” (Platform Sharing Architecture). For standard objects you can’t turn it off. For custom objects you can, in Sharing Settings.
Draw it first
Section titled “Draw it first”Before I build a hierarchy in Setup, I draw it. In class I open a spreadsheet. You can list it vertically, indenting each level: CEO, then a VP, then a manager. Or you can draw it as a tree, which is how I like to see it.
Say the CEO has three VPs: hardware, software and sales. Under hardware there’s a hardware manager, and under that, hardware support. Under software, a software manager. Under sales, a manager for each region: North America, EMEA, APAC. Each of these is a branch in the role hierarchy, and you can see at a glance who will see what. A record owned in hardware support climbs to the hardware manager, the VP of hardware and the CEO. Software never sees it. Sales never sees it.
Every role you create is a sharing decision
Section titled “Every role you create is a sharing decision”Here’s something people miss. Just by creating a role, you’re already making sharing decisions.
When you add a role, Salesforce asks for its “access to the child contacts, opportunities, and cases associated with accounts that users in the role own.” For example, users in a role can “view, but not edit, all opportunities associated with accounts that they own,” and “This access also applies regardless of who owns the opportunities” (Create a User Role). So on one branch, a manager can edit the opportunities on their accounts; on the branch below, support can only view them. Different decisions along the branch of the tree.
There are two cases where you can’t set it: when the child object’s default is Public Read/Write, “because you can’t use the role hierarchy to restrict access further than your organization-wide defaults,” and when contacts are Controlled by Parent (same page). Chapter 10, module 3 takes this setting apart, because it’s a kind of implicit sharing.
Design it for access, not as an org chart
Section titled “Design it for access, not as an org chart”How you build your role hierarchy doesn’t have to follow the organization chart. What we’re doing is about record ownership and cascading visibility. Salesforce says the same: “Role hierarchies don’t have to match your organization chart exactly. Instead, each role in the hierarchy should represent a level of data access that a user or group of users needs” (Platform Sharing Architecture).
Salesforce describes the hierarchy as starting from the org chart, a CEO with direct reports by business unit or region, and then adds the warning: “Although this sounds very much like an HR organizational chart, when modeling data access, focus on data accessibility with a consideration to HR reporting” (same page).
So what is the hierarchy for? Salesforce lists four uses (same page):
- Management access: managers see and do whatever their team can.
- Management reporting: reports roll up, so higher roles see more.
- Segregation between branches: business units don’t see each other’s data, but it still rolls up to the executives above them.
- Segregation within a role: people in the same role don’t see each other’s records. A leaf role keeps its data private and still rolls it up.
If a role doesn’t serve one of those four, ask why it’s there. Two people with the same access and the same manager usually need one role, not two, even if HR gives them different titles.
How deep, and how many
Section titled “How deep, and how many”Most hierarchies I see are two, three, four levels deep, and that’s fine. Salesforce’s line: “As a best practice, keep the role hierarchy to no more than 10 levels of branches in the hierarchy” (Platform Sharing Architecture). So don’t go beyond 10 levels unless you absolutely have to.
And how many roles? “In Salesforce orgs created in Spring ‘21 or later, you can create up to 5,000 roles. In orgs created before Spring ‘21, you can create up to 500 roles and can contact Salesforce Customer Support to increase this limit.” The best practice on the same page is to keep internal roles to 25,000 and external roles to 100,000 (Platform Sharing Architecture). Check your org’s own creation date before you plan a big hierarchy.
Why care about depth? Because of what module 1 showed. Check that one box, and all the record ownership cascades up the role hierarchy, and that can add a lot of overhead. Salesforce keeps a group for every role so it already knows who sits above whom. The deeper and wider the tree, the more there is to rewrite every time a role moves. And “When a user’s role changes, any relevant sharing rules are evaluated to correct access as necessary” (same page). For a big reorganization, Salesforce points to deferring sharing calculations, then recalculating later (Create a User Role). Chapter 22 covers that.
Overlays: the tricky part
Section titled “Overlays: the tricky part”Not everyone fits on one branch. Think of sales operations, who support every region. Or a product specialist who works deals in North America and EMEA. Salesforce calls these overlays, and it’s honest about them: “Overlays are always the tricky part of the hierarchy. If they’re in their own branch, they’ll require either sharing rules, teams, or territory management to gain needed access. If they are folded into the hierarchy, there might be reporting implications” (Platform Sharing Architecture).
So you have two choices, and both cost something.
- Their own branch. Sales operations sits beside the VPs, and sees nothing from the sales branch by itself. You open what they need with a rule (chapters 7 and 8), a team or territories (chapter 9). It’s clean, and every grant is a decision you can see.
- Folded in. You put them above the regions so the hierarchy gives them access. Now they appear in every roll-up report as if they managed those regions, and anything you put below them climbs to them.
My advice: keep the tree for the people who manage records, and bring overlays in with the other ways. Don’t add a level to the hierarchy to solve an access problem that one rule would solve.
Watch it on video
Section titled “Watch it on video”In 2023 I made a video that builds a small role hierarchy, a director, a manager and a pilot, and shows the record moving up it when the owner changes. The note under the video says what’s still right and what’s changed since.
What an architect decides here
Section titled “What an architect decides here”- The tree, drawn before it’s built, with each role standing for a level of data access, not a job title.
- For each object, whether Grant Access Using Hierarchies stays on (custom objects only).
- For each role, its access to the contacts, opportunities and cases on its accounts.
- The depth, kept at 10 levels or fewer, and the number of roles, checked against the org’s limit.
- Where overlays go: their own branch with rules, teams or territories, or folded in with the reporting cost.
- How big role changes run: when, and whether sharing calculations are deferred.
Beyond the exam: what AI changes. Agents ask the role hierarchy the same question people do. An agent working for a manager sees everything below that manager’s role, in one search. And an agent user given a role low in the tree sends everything it owns up that branch. Give agent users a role only when the hierarchy is the access you mean, and put the role where you’d put a person with that access.
Explore
Section titled “Explore”- Platform Sharing Architecture (opens in a new tab), Salesforce Architects (checked 2026-11-07): sections Role Hierarchy and Role Hierarchy Use Cases
- Create a User Role (opens in a new tab), Salesforce Help (checked 2026-11-07)