---
title: "Role hierarchy design that survives a reorg"
url: "https://trailassembly.com/role-hierarchy/"
topic: "Admin and Permissions"
published: "2026-09-10T07:32:15+00:00"
updated: "2026-10-06T13:52:00+00:00"
---

# Role hierarchy design that survives a reorg

**A role decides which records a user can see, and nothing about what they are allowed to do.** Design the hierarchy around who needs visibility into whose records, keep it as flat as those requirements allow, and treat every structural change as a recalculation event you schedule rather than a checkbox you tick.

## Roles grant record visibility upward, and that is all they do

Controlling Access Using the Role Hierarchy describes the mechanism as opening up access vertically, so that “users assigned to roles higher in the hierarchy have access to records owned by or shared with their subordinates.” A manager’s role gets them their team’s records. It gets them no object permissions, no field permissions, and no user permissions — those come from the profile and [permission sets](https://trailassembly.com/permission-sets-after-cancellation/), and a role has no ability to express them.

Conflating the two produces the most damaging design error in this area: someone can’t do something, so they get moved up the hierarchy. The immediate complaint goes away, and it is the most expensive possible fix. You have not granted a permission — you have granted visibility into every record owned by everyone beneath that role, permanently, and made it invisible to a permission audit, because nobody audits the role tree.

If a user can see a record but not edit a field, that is [field-level security](https://trailassembly.com/apex-enforcing-crud-and-fls/). If they can see it but not delete it, that is an object permission. Reach for a permission set.

## The numbers that bound your design

| Constraint | Value |
| --- | --- |
| Maximum roles, orgs created Spring ’21 or later | 5,000 |
| Maximum roles, orgs created before Spring ’21 | 500, raisable by contacting Salesforce Customer Support |
| Maximum hierarchy depth | Not documented — the guidance is qualitative |
| Recommended ceiling on records owned by one user | 10,000 per object |

I’ll be plain about that third row: I could not find an official maximum number of levels. Various figures circulate (ten is the one you’ll see most often), and none of them held up against a Salesforce documentation page that actually renders. What Guidelines for Success with Roles does say is “minimize the number of levels in your role hierarchy,” alongside “eliminate roles that aren’t needed” and delete [sharing rules](https://trailassembly.com/sharing-rules/) granting access the hierarchy already grants. Treat depth as a cost to minimise, not a budget with a known ceiling.

The 10,000-record guidance is where integration and system users trip people up. For a user who must own more than that, the recommendation is to give them no role at all, or a separate role at the top of the hierarchy, and to keep them out of public groups that might be used as the source of a sharing rule.

Removing a role is not neutral, though. Every user should normally have one, because otherwise “their data won’t display in opportunity reports, forecast roll-ups, and other displays based on roles.” An account owner with no role also shifts related-record access: contacts get Read/Write unless the OWD is Controlled by Parent, while opportunities and cases get No Access.

## Depth costs more than breadth, and here is the mechanism

Role hierarchy access is not evaluated when someone opens a record. Record-Level Access: Under the Hood explains that Salesforce calculates record access data only when configuration changes occur, then stores the result. Group Maintenance tables hold the membership — “sharing rows grant access to users and groups, but the data that specifies who belongs to each group resides in the Group Maintenance tables.”

Each role generates up to three system-defined groups: Role, RoleAndSubordinates, and RoleAndSubordinatesInternal, depending on whether digital experiences is enabled. Those groups have direct members (the users in the role), and indirect members, “who inherit record access from the group’s direct members and are assigned to manager roles.”

That is where depth gets expensive. A role added beside an existing one adds its own groups. A role added *beneath* one adds indirect membership to every group above it, to the top of the tree. The guide states the consequence: “the size and complexity of an organization’s queues and hierarchies directly affect the duration of record access calculations.”

The tradeoff runs the other way too. Visibility you remove by flattening has to come back as [sharing rules](https://trailassembly.com/sharing-rules/), and you get 300 per object with at most 50 criteria-based. Flattening a hierarchy into a wall of sharing rules can leave you worse off — more objects to maintain, a hard ceiling, and recalculation triggered by field changes instead of role changes. Aim for the fewest levels that express your real access requirements, not the fewest levels achievable.

## Design around access needs, because org charts change and hierarchies don’t move cheaply

The guidelines say it twice. “Don’t create individual roles for each title at your company” — define a hierarchy controlling access to information entered by users in lower-level roles instead. And separately: don’t let reporting requirements determine how many levels you need.

That second one gets ignored, because mirroring the org chart feels like the obviously correct starting point. It isn’t. The org chart describes who reports to whom and changes every reorganisation. Record access requirements change far more slowly. Sales still needs to see Sales. Whether there are two regional directors or four between a rep and the VP is a management decision that should never touch your sharing model.

The test I use: can I name each role by what it can see rather than by a job title? `EMEA Sales` or `Field Service - All Accounts` survives a reorg. `Senior Director, Commercial West` does not: it becomes a lie the moment the title is retired, and nobody dares delete it because they cannot work out what depends on it.

## What a role change actually costs

Designing Record Access for Enterprise Scale opens with the warning that “seemingly simple changes to groups and group membership can sometimes involve substantial recalculations of users’ access rights.” The detail behind it tells you which kind of reorg is cheap.

Moving one user between branches is the expensive case. Salesforce recalculates every sharing rule referencing the old or new role. If the user is the first member of their new role to own data, access is added or removed for everyone above both roles. And “managers in the branch above the user’s old role lose access to all the data that the user owns, as well as to child records shared through the managers’ role settings.”

Moving an entire role is cheaper: customer and partner accounts move along with their parent role, and Salesforce doesn’t have to change the related sharing. A reorg expressed as “this whole team now reports elsewhere” costs far less than the same reorg expressed as individual user reassignments, which is an argument for getting role granularity right up front.

Hence the guideline against changing the hierarchy during business hours. The reason is group membership locking: DRAES documents “could not acquire lock” and “Group membership operation already in progress” errors when hierarchy changes collide with bulk loads, integrations, or other admin work. A role change does apply the new role’s sharing rules automatically, so you needn’t re-run them, but you do need to know what those rules grant.

For a large realignment the tool is deferred sharing maintenance: suspend sharing rule and group membership calculations, then resume during a maintenance window. Deferring group membership automatically defers sharing rules too, and deferral “doesn’t defer the recalculation of some sharing changes in order to preserve data integrity.” Test the whole thing in a full copy sandbox first. The resume step is where the time goes.

## Territories are a second hierarchy, not a replacement for the first

Enterprise Territory Management gives you a parallel structure with its own sharing groups: Territory covers users in the territory plus those above it, Territory and Subordinates covers above and below. Default access is set for accounts, leads, and opportunities, plus contacts and cases when their default internal access is Private, and access inherits upward. “the territory’s access level is inherited by the parent territories above it in the territory hierarchy.”

The structural case for it: a user has exactly one role but can belong to multiple territories. If your requirement is genuinely multidimensional (a rep covering two segments in one geography) the role hierarchy cannot express it, and you will end up faking it with public groups and sharing rules.

The cost is two hierarchies, two recalculation surfaces, and territory assignment rules as one more thing that silently changes access. Territory access also works inside the OWD rather than around it. Adopt territories when the requirement is genuinely two-dimensional and permanent, not to avoid designing a role hierarchy. Orgs that do the latter end up with both problems.

## Frequently asked

### Does a role grant any object or field permissions?

No. Roles only affect which records a user can see and edit through the sharing model. Object, field, and user permissions come from the profile and assigned [permission sets](https://trailassembly.com/permission-sets-after-cancellation/), and no role assignment changes them.

### How many levels deep should a role hierarchy be?

There is no documented maximum, and I would not trust the numbers circulating for one. The documented guidance is to minimise levels for performance. Add a level only when a real group of people needs to see a real group of records and no flatter arrangement expresses it.

### Can I stop managers inheriting access on a specific object?

For custom objects, yes. Deselect Grant Access Using Hierarchies at Setup → Sharing Settings for that object. For standard objects the setting cannot be changed. It is enabled for most, though not all, of them. Users with View All Records or Modify All Records still see everything regardless.

### What happens to sharing when I move a user to a new role?

Salesforce recalculates sharing rules referencing the old and new roles, adds access for managers above the new role, and removes it from managers above the old one. Including child records shared through those managers’ role settings. On a large org this is asynchronous and can take a while, so do it outside business hours.

### Do I use roles or public groups as the target of a sharing rule?

Roles when the requirement follows the reporting structure and should include subordinates. Public groups when it does not: a deal desk, a compliance team, a set of named specialists. Groups are also cheaper to change, since altering membership does not restructure the hierarchy.

---

*Reference: [Guidelines for Success with Roles](https://help.salesforce.com/s/articleView?id=platform.setup_roles_guidelines.htm&language=en_US&type=5), [Controlling Access Using the Role Hierarchy](https://help.salesforce.com/s/articleView?id=platform.security_controlling_access_using_hierarchies.htm&language=en_US&type=5), [Role and Territory Sharing Groups](https://help.salesforce.com/s/articleView?id=sf.users_role_terr_sharing_groups.htm&language=en_US&type=5), [Define Default User Access for Territory Records](https://help.salesforce.com/s/articleView?id=sf.tm2_define_default_record_access.htm&language=en_US&type=5), [Group Maintenance Tables](https://developer.salesforce.com/docs/atlas.en-us.salesforce_record_access_under_the_hood.meta/salesforce_record_access_under_the_hood/uth_groups.htm) (Record-Level Access: Under the Hood), and [Group Membership Operations and Sharing Recalculation](https://developer.salesforce.com/docs/atlas.en-us.draes.meta/draes/draes_group_membership.htm), [Group Membership Locking](https://developer.salesforce.com/docs/atlas.en-us.draes.meta/draes/draes_group_membership_locking.htm) and [Deferred Sharing Calculations](https://developer.salesforce.com/docs/atlas.en-us.draes.meta/draes/draes_tools_deferred_sharing_maintenance.htm) (Designing Record Access for Enterprise Scale).*

---

Source: https://trailassembly.com/role-hierarchy/
Trail Assembly — independent Salesforce write-ups.