The Role Hierarchy gives users implicit access to records owned by users below them in the hierarchy, on objects where Grant Access Using Hierarchies is enabled. For most standard objects this is on by default. For custom objects you can turn it off.
Three important nuances:
- It's about ownership, not membership — if a user owns a record, every user above them in the hierarchy gets visibility. This is independent of who works on the record. So if a rep transfers ownership to a service queue, hierarchical access for the rep's manager to that record is gone — even though the manager is technically still over the rep.
- It only opens access; it never restricts — putting someone below another in the hierarchy doesn't hide records from them; it just gives the upper user access to the lower's. To hide records you need OWD (Private) plus a deliberately constructed sharing model.
- It bypasses Sharing Rules but not OWD — hierarchy-driven access is its own grant; if Grant Access Using Hierarchies is unchecked on a custom object, the role hierarchy contributes nothing to access for that object. Sharing Rules and Manual Sharing are still needed to grant cross-team access.
Where it surprises:
- Restructures. Move a director from one branch to another, and suddenly they have visibility into the new branch's data and lose access to the old branch's. There's no "look-back" — they can't see data owned by users they used to be over.
- Roles without hierarchical positioning. Users in roles that aren't connected to the rest of the tree get no hierarchy access and grant none.
- Public Groups with Grant Access Using Hierarchies. When a sharing rule grants access to a public group with the hierarchy flag on, every user above the group's members in the role hierarchy also gets access — easy to under-estimate how many people that ends up being.