The role hierarchy is not an org chart
The Salesforce role hierarchy looks like an org chart, and that resemblance is a trap. An org chart describes who reports to whom. A role hierarchy describes who inherits access to whose records. They are often similar, but they are not the same thing, and treating them as the same is a steady source of access nobody intended to grant.
What the hierarchy really controls
When an object’s sharing settings grant access up the hierarchy, a user gains access to records owned by everyone in the roles beneath theirs, all the way down their branch. A director above three managers above thirty reps can, depending on your settings, see every record those thirty reps own. Not because anyone shared those records, and not because the director asked. The hierarchy rolls that access upward automatically, every time, for every new record.
Where it drifts from the org chart
The mismatch shows up in ordinary, sensible decisions:
- An executive is placed at the top of the role hierarchy for tidiness, and quietly inherits visibility into the entire company’s records.
- A shared-services or operations role is slotted high so it can “help everyone,” and ends up able to see everyone.
- Someone changes teams, their reporting line updates in HR, but their role stays put, so their access reflects a job they no longer have.
- A role is created for one person, the person leaves, and the role lingers with whatever access it accumulated.
None of these are mistakes exactly. They are the hierarchy doing precisely what it is designed to do, applied to a structure that was built to mirror reporting rather than to scope access.
The question that exposes it
A useful habit is to stop asking “does this hierarchy match our org chart?” and start asking “for each high role, is the access it inherits actually appropriate?” Those are different questions. The first is about neatness. The second is about risk. A role can sit in exactly the right place on the chart and still inherit far more record access than the person in it needs.
Seeing inherited access for what it is
Inherited access is hard to audit by eye because it is implicit. There is no sharing rule to point at and no manual share to review. The access simply exists because of where a role sits. Who Sees What makes that visible: when it shows who can see a record, it names the role hierarchy as the reason whenever that is what granted access, so inherited visibility stops being invisible. You can look at a senior role and see the full footprint of what it can reach, then decide whether that footprint is the one you want.
The fix is rarely to tear up the hierarchy. It is to separate the two ideas in your head, build the hierarchy for access rather than for aesthetics, and keep a way to check what each level actually inherits. Your org chart can stay a picture of your company. Your role hierarchy should be a deliberate description of who gets to see whose work.