A user can see a record they shouldn't — how to find why

Why can this person see that record? is the most common access question in Salesforce — and the hardest to answer by eye, because the platform never decides visibility in one place. It grants the union of several mechanisms. This guide gives you a repeatable order to find the one that opened access.

First, the mental model

Salesforce sharing is additive and most-permissive-wins. You are not looking for a rule that allows access and a rule that blocks it. You are looking for any single grant, because one is enough. (For the full layering, see who can see a record in Salesforce.)

If even one mechanism grants access, the user has it. Your job is to find which one.

Step 1 — Read the Sharing button

On the record, click Sharing (available for objects whose org-wide default isn’t fully public). The list shows users with access and a Reason column — Owner, Role Hierarchy, Sharing Rule, Manual Share, Team, and so on. For most cases this names your culprit immediately.

If the user isn’t even listed there but still sees the record, suspect a profile-level bypass — go to Step 2.

Step 2 — Rule out permission-level bypasses

These ignore the sharing model entirely:

• View All Data / Modify All Data (system permissions, e.g. on the System Administrator profile).
• Object-level View All / Modify All on that specific object.

If the user has any of these via profile or a permission set, sharing changes won’t hide the record. You must remove the permission. Check their profile and every assigned permission set.

Step 3 — Walk the sharing layers, top to bottom

If it’s genuinely a sharing grant, identify which layer:

Org-wide default is too open

If the object’s OWD is Public Read Only or Public Read/Write, everyone with object access sees every record. The fix is structural — tighten the org-wide default and re-grant access deliberately.

Role hierarchy rolling access upward

If the user sits above the record owner in the role hierarchy and “Grant Access Using Hierarchies” is on, they inherit the owner’s access automatically. This is the most common surprise.

An over-broad sharing rule

A criteria-based rule like Region = EMEA → share with role X can include far more people than intended, especially after data or role changes. Review the rules targeting the user’s role, public groups, or territory.

A manual or implicit share

• Manual share: someone used the record’s Share button.
• Implicit share: access to a parent Account grants limited read access to its child Cases and Contacts. People forget this one constantly — and it’s always read-only.
• Apex managed sharing: custom code created the share; the Sharing button shows it but the origin is in code.

Teams and territories

Account/Opportunity/Case team membership, or a matching territory under Enterprise Territory Management, each grant access independently.

Step 4 — Confirm it isn’t recalculation lag

If access looks inconsistent, you may be watching sharing recalculation finish after a recent ownership, role, or rule change. Let it complete before declaring a bug.

A diagnosis checklist

1. Sharing button → read the Reason for that user.
2. Profile + permission sets → any View All / Modify All?
3. OWD too open for this object?
4. User above the owner in the role hierarchy?
5. Any sharing rule (esp. criteria-based) including them?
6. Manual, implicit, or Apex share?
7. Team member or matching territory?
8. Recent change → wait for recalculation.

The first “yes” is your answer — and there may be more than one path granting the same access. For the opposite problem — a user who can’t see a record they should — see the diagnosis checklist for missing access.

Doing this in seconds instead of an afternoon

Walking eight layers per user-record pair, across profiles, permission sets and six sharing mechanisms, is exactly the manual grind that hides real exposure. AgentForceAccess does it for you: ask in plain English why a user can see a record, and it traces every layer and cites the precise grant — so you go straight to the fix.

Frequently asked questions

What is the fastest first check?

Open the record, click the Sharing button, and read the "Reason" column for that user. It names the mechanism granting access — Owner, Role Hierarchy, Sharing Rule, Manual, and so on — for most standard objects. Also confirm the user does not simply have "View All Data" or object-level "View All".

The Sharing button says "Role Hierarchy" — what now?

Someone the user sits above in the role hierarchy owns the record (or has it shared with them), and "Grant Access Using Hierarchies" is enabled for the object. To remove that access you would change the hierarchy, the ownership, or disable hierarchy access for custom objects — none lightly.

Could a profile permission, not sharing, be the cause?

Yes. "View All Data"/"Modify All Data" and object-level "View All"/"Modify All" bypass the sharing model entirely. If the user has any of these, no sharing change will hide the record — you must remove the permission instead.

Why does access appear and disappear intermittently?

Sharing recalculation. After ownership changes, role moves, or rule edits, Salesforce reprocesses shares asynchronously. During that window access can look inconsistent. Let recalculation finish before concluding there is a configuration bug.