Why Can This User See This Record?

It is the most common ticket in any admin's queue: "Why can this person see this record?" or its evil twin, "Why can't they?" The question sounds simple. Answering it is not, because access in Salesforce can originate from almost anywhere.

Why it is hard

A single user's access to a single record can come from any of these, alone or in combination:

• their profile (object permissions, View All / Modify All, View All Data / Modify All Data)
• any number of assigned permission sets
• a permission set group they belong to
• a muting permission set that subtracts from a group
• record ownership
• the role hierarchy rolling access upward
• sharing rules (owner-based or criteria-based)
• account, opportunity, or case teams
• a one-off manual share
• implicit parent-child sharing you cannot turn off

To answer the question manually, you open the user, read their profile, open every permission set, open every group, check ownership, walk the role hierarchy, scan the sharing rules, and finally open the record's sharing detail. For a real org this is twenty minutes of clicking — per question. (For the full breakdown of these layers, see The 10 layers of record access.)

The manual trace

If you do it by hand, work top-down and stop at the first thing that grants access:

Does the profile or a permission set carry View All Data or object View All? If yes, you are done — sharing is irrelevant.

Does the user own the record, or sit above the owner in the role hierarchy?

Is there a sharing rule that puts the record in front of the user's role or a group they are in?

Is the user on a team for the parent record, or is there a manual share?

Is access implicit through a parent the user can already see?

The trouble is that each of those checks is a different Setup screen, and "the first thing that grants access" is exactly what you do not know going in.

The one-click answer

This is the entire reason Explain Access and Permission Chain exist in SFDC Police. Point them at a user and a record (or a user and a permission) and you get the answer with the source attached:

• Explain Access returns a verdict — Granted or Denied — and the exact grant path. Not "they probably have a sharing rule," but "Granted via the Modify All Data system permission on the System Administrator profile."
• Permission Chain traces a permission back through the full dependency stack — Profile, Permission Sets, Permission Set Groups, and Muting Permission Sets — with source tracking at every step, so you see which assignment is responsible.

From there you can go further:

• Who Has Access runs the question in reverse: instead of "why can this user see this," ask "which users can see this field or object?" and get the list.
• Compare Users puts two users side by side and highlights exactly where their effective access differs, with export to CSV, JSON, TSV, or the clipboard for audit evidence.

Why source tracking matters

Knowing that access exists is half the answer. Knowing where it comes from is the half that lets you act. If a user can see a record through a sharing rule, you fix the sharing rule. If it is a stale permission set from a role they left a year ago, you remove the assignment. If it is View All Data they never should have had, that is a security finding, not a sharing tweak.

Without source tracking, every fix is a guess. With it, "why can this user see this record?" goes from a twenty-minute investigation to a single, citable answer.

Read the Permission Chain documentation, or learn how the same engine maps a record across all ten access layers in Access X-Ray.