Sharing rulesRole hierarchySalesforce admin

Sharing rules vs role hierarchy in Salesforce: the difference

Role hierarchy grants access automatically up the org chart; sharing rules extend access sideways by criteria or ownership. When to use each, with examples.

AgentForceAccess 3 min read
A vertical role-hierarchy pyramid beside horizontal peer-to-peer sharing arrows

Role hierarchy and sharing rules are the two mechanisms admins reach for most — and the two most often confused. They both widen record access, but in different directions and for different reasons. Getting the distinction right is the difference between a clean sharing model and a tangle of overlapping rules.

The one-line difference

  • Role hierarchy — grants access automatically and vertically: anyone above the record owner in the org chart inherits the owner’s access.
  • Sharing rules — grant access deliberately and horizontally: to peers, other teams, or groups the hierarchy would never connect, based on ownership or field criteria.

Both sit on top of the org-wide default and can only open access, never restrict it. (See the full layering in who can see a record.)

Role hierarchy: access rolls upward

When Grant Access Using Hierarchies is enabled for an object, managers automatically inherit access to records owned by — or shared with — users below them. No rule, no configuration per record.

Example. A Private org-wide default on Opportunities. A rep owns a deal. Their manager, and the manager’s VP, can see it automatically because they sit above the rep in the hierarchy. That’s the role hierarchy doing its job.

This is perfect for manager-sees-team visibility, and it’s also the most common source of “why can they see this?” surprises — because nobody configured it per record.

Sharing rules: access opens sideways

Sharing rules extend access across the hierarchy, to users the org chart keeps separate. Two flavours:

  • Ownership-based — share records owned by one group (role, public group, territory) with another group.
  • Criteria-based — share records that match field values (e.g. Region = EMEA) with a group, role, or territory.

Example. EMEA and APAC sales are separate branches of the hierarchy, so neither sees the other’s deals. A criteria-based rule — Region = EMEA → share Read with the APAC Leadership group — opens exactly that cross-branch access without touching the hierarchy.

When to use which

NeedUse
Managers see their team’s recordsRole hierarchy
Access follows reporting lines automaticallyRole hierarchy
Two peer teams must see each other’s recordsSharing rule (ownership-based)
Share records matching field criteria (region, type, stage)Sharing rule (criteria-based)
Share with a public group or territorySharing rule
One-off access to a single recordManual share (not either of these)

They stack — and that’s the gotcha

Because access is additive and most-permissive-wins, the role hierarchy and sharing rules combine. A user can gain access to one record through the hierarchy and through two sharing rules at once. None of them overrides the others; any single one is sufficient.

That’s also why over-broad sharing creeps in: each rule looks reasonable alone, but the union across hierarchy + rules + manual shares is what a user actually sees — and nobody holds that whole picture in their head.

Neither one restricts — by design

If you need to reduce access, sharing rules and the role hierarchy can’t help. Tighten the org-wide default, or use restriction rules. Adding another sharing rule can only ever open more access.

Seeing the combined effect

The hard part isn’t either mechanism — it’s their sum. To know why a user sees a record you have to evaluate the hierarchy and every applicable sharing rule and manual shares together.

AgentForceAccess computes that union for you: ask why a user can see a record and it tells you whether it’s the role hierarchy, a specific sharing rule, or both — in plain English, with the mechanism cited.

Frequently asked questions

What is the core difference in one sentence?

The role hierarchy opens access upward and automatically along reporting lines, while sharing rules open access sideways and on purpose, to users a hierarchy would never connect.

If both could grant access to the same record, which wins?

It does not matter — Salesforce access is additive and most-permissive-wins. If either the role hierarchy or a sharing rule grants access, the user has it. You never need both to "agree".

Can a sharing rule take access away?

No. Sharing rules and the role hierarchy can only extend access above the org-wide default. To reduce access you change the org-wide default, or use restriction rules — not sharing rules.

Do I still need sharing rules if my role hierarchy is well built?

Usually yes. A hierarchy only expresses vertical, manager-over-report access. The moment two peer teams, or a role in another branch, need to see each other's records, only a sharing rule can express that.

See it on your own org

AgentForceAccess explains, in plain English, why any user can see any record or file — across every Salesforce sharing mechanism.

Request early access