The 10 Layers of Record Access

Record access in Salesforce is evaluated as a series of ten distinct layers. A user must pass through all layers to view, edit, or delete a record. Understanding each layer helps you diagnose permission issues quickly.

Layer 1: Object Permissions

Before a user can access a record of any type, they need object-level CRUD (Create, Read, Update, Delete) permissions. These come from their assigned profile or permission sets.

Read permission grants viewing rights to all records of that object type
Create allows creating new records
Update allows editing existing records
Delete allows deleting records

The View All and Modify All checkboxes bypass all lower layers for that object — users with these checked get access to every record, regardless of ownership or sharing rules.

Layer 2: Org-Wide Defaults

Org-Wide Defaults set the baseline sharing model for each object: Private, Public Read Only, or Public Read/Write. If an object is set to Private, users can only see records they own or that are explicitly shared with them. If it's Public Read/Write, all users with Read/Update permissions can see and edit all records (assuming no other layers block them).

Layer 3: Ownership

In a Private org-wide default, record ownership determines access. The record owner and users above them in the role hierarchy can see and edit the record. Users below them in the hierarchy cannot, unless the record is shared with them via Layer 5 (sharing rules) or Layer 7 (manual shares).

Layer 4: Role Hierarchy

The role hierarchy creates a permission "flow" — users in parent roles can see and edit records owned by users in child roles (if the org-wide default and object permissions allow it). If a user's role is above the owner's role in the hierarchy, they inherit access. If below, they do not.

Layer 5: Sharing Rules

Sharing rules automatically grant access based on criteria (owner-based or criteria-based). An owner-based sharing rule says "if the record owner is in group X, also grant access to group Y." A criteria-based sharing rule says "if the record meets condition Z (e.g., Stage = Closed), grant access to group Y."

Sharing rules work at the object level and grant either Read-only or Read/Write access. They apply to all records matching the rule, automatically.

Layer 6: Territory Management

Territory management (if enabled) assigns records to territories, and territories to users. Users assigned to a territory can see all records assigned to that territory. Territory hierarchies also allow users to see records in child territories, similar to role hierarchy.

Layer 7: Teams

Teams (Account Teams, Opportunity Teams, and Case Teams) allow explicit, record-level sharing without formal sharing rules. The record owner adds team members directly to a specific record. Teams can grant Read or Read/Write access.

Layer 8: Manual Shares

Manual shares let the record owner (or admins) explicitly share a single record with a user or group. This is the "most granular" layer — one user gets access to one record. Manual shares can be Read-only or Read/Write.

Layer 9: Implicit Parent-Child Sharing

If a user has access to a parent record, they implicitly see child records (e.g., Contacts owned by a shared Account). This is automatic — you don't set it up, but it applies whenever a child field is a master-detail relationship.

Layer 10: System Permissions

System permissions like View All Data and Modify All Data override all other layers. A user with View All Data can see every record in the org, regardless of object permissions, org-wide defaults, ownership, sharing, or anything else. Modify All Data does the same for updates and deletes.

After Record Access: Field-Level Security & Layout Control

Even if a user passes all ten record access layers, two more gates apply:

Field-Level Security (FLS) — Applied per field within the object. If a user lacks Read permission on a field, they cannot see it even if they can see the record. If they lack Edit permission, they cannot modify it. Page Layout & Lightning Page Assignment — A user's assigned page layout determines which fields, sections, and buttons appear when they view a record. A field not on their page layout is hidden from their view, even if they have FLS Read permission. Similarly, Lightning Page assignments determine which components they see. Record Type Assignment — A user's record type assignment limits which record types they can create or access. If a user is not assigned a record type, they cannot work with records of that type.

How Access X-Ray Maps the Layers

The Access X-Ray feature in the SFDC Police floating panel evaluates all ten layers for a specific record and user in real time. For each layer, it reports:

Whether the user has access at that layer
The reason (e.g., "owned by user," "shared via rule X," "user has View All Data")
Actionable next steps if access is blocked

This helps you quickly identify which layer is the blocker. For example, if a user claims they can't edit a record, Access X-Ray shows whether the issue is object permissions (layer 1), org-wide defaults (layer 2), ownership (layer 3), or FLS (field-level gate).

See The 10 Layers of Record Access in the blog for real-world examples.