Who can see a record in Salesforce? How access is actually decided

If you administer a Salesforce org for long enough, someone will eventually ask: “How is this person able to see that record?” The honest answer is that Salesforce never decides record visibility in one place. It layers several mechanisms on top of each other and grants the union of them all.

This guide walks through each layer in the order Salesforce evaluates it, so you can reason about any “who can see what” question from first principles.

The one rule that explains everything

Salesforce sharing is additive and most-permissive-wins. Start from the baseline set by org-wide defaults, then every other mechanism can only add access on top. Nothing in the standard sharing model takes access away.

So when you are tracing why a user can see a record, you are never looking for the rule that allows it and a rule that blocks it. You are looking for any single grant — because one is enough.

If even one mechanism grants access, the user has access. Full stop.

Layer 1 — Object permissions decide if, not which

Before sharing is even considered, the user needs object-level access through their profile or permission sets:

• Read / Create / Edit / Delete on the object.
• View All or Modify All on the object, which ignore sharing for that object entirely.

If a user has no Read permission on Opportunities, no sharing rule in the world will show them an opportunity. Object permissions are the gate; the sharing model is what happens after you pass through it.

Layer 2 — Org-wide defaults set the floor

Org-wide defaults (OWD) define the most restrictive baseline for each object:

• Private — only the record owner (and people above them in the role hierarchy) can see it.
• Public Read Only — everyone can view, only the owner can edit.
• Public Read/Write — everyone can view and edit.

Everything that follows exists to widen access above this floor for specific people.

Layer 3 — Role hierarchy rolls access upward

If Grant Access Using Hierarchies is enabled for the object, anyone above the record owner in the role hierarchy inherits the owner’s access. This is why a sales manager sees their reps’ deals without any explicit rule — and it’s the single most common reason for surprise access.

Layer 4 — Sharing rules open access sideways

Sharing rules extend access across the hierarchy, to peers and other branches:

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

Both grant access to a group of users at once, which makes an over-broad criteria-based rule a frequent culprit when “too many” people can see something.

Layer 5 — Manual and implicit shares

• Manual sharing — the Share button on a record, granting one specific user or group access to that one record.
• Implicit sharing — built-in behavior, such as access to a parent account implying limited access to its child cases and contacts.
• Apex managed sharing — programmatic shares created by custom code, often the hardest to spot.

Layer 6 — Teams and territories

• Account, Opportunity and Case teams grant the listed team members access to that record.
• Enterprise Territory Management grants access based on the territories a user and a record belong to.

Putting it together: how to trace any access

To answer “why can this user see this record,” check each layer until you find a grant:

1. Does the user have object Read (or View All) via profile/permission set?
2. Is the OWD already public for this object?
3. Are they above the owner in the role hierarchy?
4. Does any sharing rule include them?
5. Is there a manual, implicit, or Apex share?
6. Are they on a team, or in a matching territory?

The first “yes” is your answer — and remember there may be more than one. For the step-by-step version of this trace, see a user can see a record they shouldn’t; the same model governs who can see a file, since files inherit record access.

This is exactly the work AgentForceAccess automates: ask in plain English why a user can see a record, and it traces every layer above and cites the precise grant that allows it.

Frequently asked questions

Does a System Administrator bypass the sharing model?

Yes. The "View All Data" and "Modify All Data" permissions — granted to the System Administrator profile by default — bypass org-wide defaults, sharing rules and role hierarchy entirely. Object-level "View All" / "Modify All" do the same for a single object.

If two sharing rules apply to the same record, which one wins?

The most permissive one. Salesforce access is additive: it grants the union of every applicable rule. Access can never be reduced by adding another rule — only widened.

Why can a manager see records they were never explicitly given?

The role hierarchy grants managers access to records owned by (or shared with) users below them in the hierarchy, as long as "Grant Access Using Hierarchies" is enabled for that object.

Do object permissions and sharing settings do the same thing?

No. Object permissions (on profiles and permission sets) decide whether a user can access an object at all and what they can do with it. The sharing model decides which specific records of that object they can see.