Every access design eventually produces the same Slack message: "why can they see this?" You trace it through roles, then sharing rules, then a manual share from 2022, then a permission set nobody remembers assigning. Two hours later you find it. The model was never complicated. It was just spread across nine Setup screens with no single map.
This is that map. The full one-page cheatsheet is in the PDF: drop your work email further down the page and the printable copy lands in your inbox in seconds. The summary below is the shape of what is inside, so you know exactly what you are getting.
Law that explains the entire model
Gates every value must pass (WHAT · WHO)
Rungs on the record-access ladder
And only two ways to subtract access
The one law that explains the whole model
Salesforce record access only ever ADDS. Roles, sharing rules, teams, Apex shares: every one of them stacks more access on top. There is no such thing as a restrictive sharing rule. Once you internalize that, the "why can they see this?" question always has an answer, because some path granted it and nothing ever took it away.
To take access away you have exactly two record-level levers: lower the floor with OWD, or build a Restriction Rule wall. That is the whole subtraction toolkit. If you reach for anything else to remove access, you are about to over-grant instead.
Two gates, one AND
Access is two questions asked in sequence, not one. The first is a WHAT question about the kind of data. The second is a WHO question about the specific record. You need both gates open to see a single value, and only two narrow tools ever pull you back down.
Object + Field
Can you touch this kind of data at all? Profiles, permission sets, and field-level security decide it.
Record Access
Can you touch this specific record? A ladder that only climbs: you get the highest rung any path reaches.
The Two Walls
You need both gates open to see a value. The only things that pull you back down: Restriction Rules (WHO) and Muting Permission Sets (WHAT).
Gate 1: the WHAT (object and field)
Your profile is the baseline, and every user has exactly one. Permission sets and permission set groups stack on top of it, always additive. The only wall on this side is the Muting Permission Set, and it works only inside a permission set group: it mutes the object, field, and system permissions granted by that group's other sets. It cannot touch the profile.
View All and Modify All (per object), plus View All Data and Modify All Data (org-wide), are a sharing bypass. They ignore OWD, the role hierarchy, and every sharing rule. But FLS still applies: you still need the field, or "View All Fields." FLS is field visibility given object access, enforced in the UI, reports, search, and the standard APIs.
One footnote worth keeping straight: the "permissions leave profiles" retirement was postponed, not enforced. Permission-set-led is still best practice, but profiles keep login hours and IP ranges, default record types and apps, and page-layout assignment.
Gate 2: the WHO (the ladder that only climbs)
Record access is a ladder, and the most-permissive grant wins. You do not average the rungs or take the last one applied. You get the highest rung any path reaches. That single fact resolves almost every access mystery.
Most-permissive grant wins. You get the highest rung any path reaches.
- 1
OWD (Org-Wide Defaults)
Sets the baseline floor every other rung climbs from.
The catchInternal and external access are separate settings, and external can never exceed internal.
- 2
Role Hierarchy
Rolls access up to managers via 'Grant Access Using Hierarchies'.
The catchForced on for standard objects, off-able only for custom objects. The usual source of 'why can they see this?'
- 3
Sharing Rules
Owner-based or criteria-based grants to public groups, roles, or territories.
The catchOpen-only. They grant Read or Read/Write and can never restrict. There is no such thing as a restrictive sharing rule.
- 4
Manual / Teams
The 'Share' button (only when OWD is below Public Read/Write). Account, Opportunity, and Case Teams are the same thing with a nicer UI.
The catchBoth are deleted on owner change. Never build a process that depends on a manual share surviving.
- 5
Apex Managed Sharing
Rows written under a developer-defined sharing reason.
The catchSurvives owner change. The durable fix when manual shares keep vanishing on you.
- 6
Implicit Sharing
Native, always on, can't toggle. Runs in both directions (child to account and back).
The catchSince Winter '24, Account to Case/Contact/Opportunity child shares are computed at query time with no stored rows. Other implicit shares still persist.
The OWD values in full, since most cheatsheets get this wrong: Private, Public Read Only, Public Read/Write, Public Read/Write/Transfer (Lead and Case), Public Full Access (Campaign), and Controlled by Parent (the master-detail detail side, for example a Contact under an Account). Price Books use a separate set entirely: Use, View Only, or No Access.
On grant levels: sharing rules cap at Read/Write, but manual and Apex shares can grant Full Access (transfer, delete, and reshare) on the objects that support it.
The most-botched pair in the whole model
These two get confused constantly, and the confusion is expensive because one is a real security boundary and the other is not. A Restriction Rule is a wall. A Scoping Rule is a default lens.
Restriction Rule
Subtractive. Removes access a user would otherwise have. Enforced on reports, list views, SOQL and SOSL, search, lookups, related lists, and the API. A real security boundary.
Exception: View All / Modify All users are exempt. (Enterprise and up, limited object set.)
Scoping Rule
Sets what you see by default on SOQL, reports, and list views only. The user can switch scope and still reach every record they have access to. Not security.
If a list-view filter can defeat it, it was never security.
The one bug that ships to prod
Here is where good engineers get burned. The with sharing, without sharing, and inherited sharing keywords control Gate 2 (records) only. They never touch Gate 1. Your with sharing Apex still happily returns fields the user cannot see, unless you enforce FLS yourself. Sharing-safe is not field-safe.
Silent over-exposure paths
Sharing-safe is not field-safe. Five ways access leaks even when the sharing looks right.
- with sharing Apex controls records, never fields. It returns fields the user can't see unless you enforce FLS yourself.
- Record-triggered Flows still default to system mode. They run past both gates unless you scope them deliberately.
- Legacy Apex on API v66.0 or older keeps the old system-mode behavior after Summer '26, even as new classes tighten.
- Manual shares and Account, Opportunity, or Case Teams are deleted the moment the record owner changes.
- A scoping rule any list-view filter can defeat was never a security control. Don't lean on it as one.
The 2026 watch: on API v67.0 (Summer '26), database operations default to user mode (enforcing sharing, FLS, and CRUD), classes with no sharing declaration now default to with sharing, and WITH USER_MODE replaces WITH_ENFORCED. Classes on v66.0 or earlier keep the old system-mode behavior, and record-triggered Flows still default to system mode. That Flow default is the silent over-exposure path most teams never audit.
The Monday-morning litmus test
Three questions to run before you build anything that touches access. Each one catches the mistake that shows up in the audit six months later.
“Exactly two tools: the OWD floor, or a Restriction Rule wall.”
Reached for anything else, a 'restrictive' sharing rule, a clever role tweak, a scoping rule? You are about to over-grant. The model only adds, and those two levers are the only way down.
“Then you've already lost.”
Using a sharing bypass to fix a sharing problem means the design is the problem. View All and Modify All ignore OWD, roles, and every sharing rule. Reach for them and you have stopped modelling access and started routing around it.
“Sharing answers WHO. Permissions answer WHAT.”
Never fix a WHO problem with a WHAT tool, or the reverse. Can't see the record? That is Gate 2, sharing. Can't see the field? That is Gate 1, FLS. Mixing them is how orgs end up handing out System Administrator to patch a sharing rule.
Where this came from
Neil Sarkar (Co-Founder, Clientell) built this from auditing 1,000+ orgs where the access model had drifted so far that nobody could answer "who can see this record, and why" without a two-hour investigation. The PDF is the one-page reference our team pins next to every access review, so the answer takes a minute instead.
Clientell audits your entire access model and explains what is broken in plain English: OWD, roles, sharing rules, FLS, restriction rules, all of it. Start with the free Salesforce Permissions Audit, or go deeper with the Salesforce Permissions Audit Checklist. If you are evaluating an AI agent that will touch this model, the 50 Things to Check Before Using Any AI for Your Salesforce Work covers the permissions and blast-radius side in full.