When a user clicks on a record in Salesforce, the platform makes an instant decision: can this user view it? Can they edit it? That decision isn't simple. It's the result of ten sequential checks, each one capable of granting or blocking access. Understanding these layers is the difference between a permission setup that works and one that leaks data or locks out legitimate users.

Layer 1: Object Permissions

The first gate is the object permission itself. If a user's profile or permission set doesn't grant Create, Read, Update, or Delete on the object, the record is invisible.

But there's a wrinkle: a permission set can flip View All or Modify All on an object. View All Data grants read access to every record of that object, regardless of ownership or sharing. Modify All Data grants full edit access. These system permissions bypass all nine of the sharing rules that come next.

Layer 2: Org-Wide Defaults

Org-Wide Defaults (OWDs) set the baseline sharing posture for each object. The options are Private, Public Read Only, Public Read/Write, and Controlled by Parent.

If the OWD is Private, a user can see only records they own or that have been explicitly shared with them. If it's Public Read/Write, every user in the org can see and edit every record on that object — and the remaining sharing layers just tighten access further, they never broaden it.

Layer 3: Record Ownership

If the user owns the record, they can see and edit it (unless the OWD is Private and their role doesn't grant access through other means). Ownership is explicit: the Owner field on the record.

Layer 4: Role Hierarchy

Role hierarchy grants implicit sharing "up the ladder." If User A reports to User B, User B can see all of User A's records by default (unless the OWD is Private and the role hierarchy sharing is disabled, or unless the record is shared only downward). This is often the first sharing rule admins forget about — it's silent and powerful.

Layer 5: Sharing Rules

Sharing rules come in two flavors: owner-based and criteria-based. Owner-based rules grant access to all records owned by a specific user or role. Criteria-based rules grant access to records that match a condition.

These rules always broaden access; they never restrict it. If the OWD is Private and no sharing rule applies to the user, they don't see the record.

Layer 6: Account Teams, Opportunity Teams, and Case Teams

Teams are a lightweight alternative to sharing rules. If a record has a team associated with it and the user is on that team, they get the access level assigned to their team role.

Layer 7: Manual Shares

A record owner can manually grant access to the record to a specific user or group. This is one-off sharing, not rule-based.

Layer 8: Implicit and Built-In Sharing

Some objects implicitly share records based on parent-child relationships. If you have read access to a parent record, you can often read its child records. The details depend on the object model.

Layer 9: Territory Management

Territory management is an overlay for Accounts, Opportunities, and related objects. If you own a territory or are assigned to one, you can see and potentially edit records in that territory.

Layer 10: System Permissions

Finally, system permissions like Modify All Data and View All Data act as a master key. If a user has View All Data, they see every record, period. If they have Modify All Data, they can edit every record.

These permissions are often granted to admins, but they accumulate through profiles, permission sets, and permission set groups. Finding every user with these permissions is a critical security audit — and surprisingly hard to do manually.

Beyond Record Access: The Final Gates

Even after passing all ten layers, a user still faces two more barriers to actually seeing and editing a record.

Field-Level Security (FLS) controls which fields are visible and writable. You might have full edit access to a record, but FLS can hide the Salary field or make it read-only. Page Layout and Record Type assignment control which fields appear on the detail page and which relate to which record type. A user might have access to the record but not see all the fields because their page layout excludes them.

The Access X-Ray Shortcut

Tracing these ten layers manually is tedious. You'd need to check the user's profile, all assigned permission sets, the OWD, the role hierarchy, sharing rules, teams, manual shares, territory assignments, and system permissions.

SFDC Police's Access X-Ray breaks this down instantly. Point it at any record and any user, and it returns a 10-layer (L1–L10) verdict: which exact layer grants or blocks access, and the source of each decision. No setup required, no API keys, no data ever leaves your browser.

From there, you can open the Permission Chain to trace the full permission source (which profile or permission set?) and use Explain Access for a user to audit their access across multiple records.

See the features page to get started, or read Why Can This User See This Record? for a practical walkthrough.

The 10 Layers of Salesforce Record Access