The Salesforce security model is layered — each layer answers a different question, and a user gets access to a record only if every layer permits it. Interviewers love this question because a strong answer walks through all four layers in order without missing any. The four layers are: organization-level, object-level, field-level, and record-level.
Layer 1 — Organization-level security
This is the perimeter. It controls who can log in at all and from where:
- Trusted IP ranges on the profile (no MFA prompt) or org-wide.
- Login IP restrictions on the profile (hard block outside the range).
- Login hours on the profile (block logins outside business hours).
- Session settings (timeout, lock to IP, HTTPS-only, high-assurance sessions).
- Multi-factor authentication (required for direct logins since Feb 2022).
- Password policies (length, complexity, history, expiration).
If any of these fail, the user never reaches the app — object and record permissions are irrelevant.
Layer 2 — Object-level security (CRUD)
Once a user is in, profiles and permission sets decide whether they can interact with each object at all. The four CRUD permissions per object are Create, Read, Edit, Delete. Plus two power permissions: View All and Modify All for that object, which bypass record-level sharing.
If a profile or any assigned permission set grants Read on Account, the user can open the Account tab. If none of them do, the Account tab is invisible.
Layer 3 — Field-level security (FLS)
Within an object the user can see, FLS controls which fields they can read or edit. FLS is set per profile and per permission set. A field hidden by FLS is invisible in page layouts, list views, reports, the API, search results, and SOQL — it’s a true platform-wide hide, not just a UI hide.
Layer 4 — Record-level security (sharing)
Even with full CRUD on Account and full FLS, the user still only sees the specific Account records they’re entitled to. Record access is built bottom-up from the most restrictive baseline:
- OWD (Organization-Wide Defaults) — the most restrictive starting point: Private, Public Read Only, Public Read/Write, Controlled by Parent.
- Role hierarchy — “Grant Access Using Hierarchies” opens records owned by users below in the hierarchy.
- Sharing rules — owner-based or criteria-based, opening records to groups, roles, or territories.
- Manual sharing — one record shared to one user/group by the owner.
- Team-based sharing — Account, Opportunity, and Case teams.
- Apex / programmatic sharing —
__Sharetable rows inserted from code. - Implicit sharing — built-in shares (e.g., account access for opportunity owners).
Each layer can only grant access on top of OWD — none can revoke it. The final access is the most permissive grant across all layers.
A worked mental model
| Question the platform asks | Layer answering it |
|---|---|
| ”Can you log in right now?” | Org-level (IP, hours, MFA) |
| “Can you open the Account object at all?” | Object-level (CRUD on profile + perm sets) |
| “Can you see the Amount field on this record?” | Field-level (FLS on profile + perm sets) |
| “Can you see this specific Account record?” | Record-level (OWD → hierarchy → sharing) |
| “Can you edit it?” | All four layers must permit edit |
If any one of these is “no,” the user is blocked. That’s the whole model.
Where each thing lives in Setup
- Login hours, IP ranges, session settings: Setup → Session Settings, Setup → Profiles.
- Object & field permissions: Setup → Profiles or Setup → Permission Sets.
- OWD, role hierarchy, sharing rules: Setup → Sharing Settings.
- Manual sharing: the Sharing button on each record (Lightning) or Sharing detail row (Classic).
Common interview follow-up
“What’s the order of evaluation when a user tries to view a record?”
Top down: org-level (can they log in?) → object CRUD (can they read the object?) → FLS (which fields?) → record sharing (does any sharing layer grant access to this record?). If View All / Modify All / View All Data / Modify All Data is granted at the object or system level, record-level checks are bypassed.
Verified against: Salesforce Help — Strengthen Your Data’s Security and Sharing & Visibility Architect resources at architect.salesforce.com. Last reviewed 2026-05-17.