Security — Who Sees What
Org-wide defaults, role hierarchy, sharing rules, profiles vs permission sets and field-level security, with a worked example.
Admin 2 min readSecuritySharingProfilesPermission setsOWD
Salesforce security has three layers. Answer "can this user see/edit this?" by walking them in order.
| Layer | Question it answers | Tools |
|---|---|---|
| Object | Can the user access Accounts at all? | Profiles, permission sets |
| Field | Can they see/edit the Salary field? | Field-level security (FLS) |
| Record | Which Account records? | OWD, role hierarchy, sharing rules, teams, manual sharing |
Object & field permissions
- Profile: every user has exactly one — baseline (login hours, page layouts, default apps, some permissions).
- Permission set: extra permissions added on top; a user can have many.
- Permission set group: bundle permission sets for a job role (e.g. "Sales Ops").
- Salesforce recommends minimal profiles + permission sets for everything else.
CRUD = Create, Read, Edit, Delete; plus View All / Modify All on an object.
Record access — most restrictive first
- Organization-Wide Defaults (OWD) — the baseline:
Private,Public Read Only,Public Read/Write,Controlled by Parent. - Role hierarchy — managers see their subordinates' records (can be disabled for custom objects via "Grant Access Using Hierarchies").
- Sharing rules — open access further, based on owner (role/group) or criteria (field values).
- Manual sharing / teams — ad-hoc access for specific records.
- Apex managed sharing — programmatic (
Account__Share/AccountSharerecords).
Sharing only opens up access — you can never use it to restrict below OWD.
Worked example
Requirement: Sales reps see only their own Opportunities; managers see their team's; Finance sees all closed-won deals read-only.
- OWD Opportunity = Private.
- Role hierarchy: Sales Manager above Sales Rep → managers see reps' deals.
- Criteria-based sharing rule:
Stage = Closed Won→ share with Finance public group, Read Only. - Finance users' permission set: Read on Opportunity; FLS hides
Discount_Reason__c.
Other access tools
- Public groups — users, roles, other groups; used by sharing rules and queues.
- Queues — record ownership by a group (Leads, Cases, custom objects).
- Login IP ranges / hours on profiles, MFA, session settings.
- Restriction rules — reduce visibility of records users would otherwise see (supported objects).
Interview questions
- A user can't see a field on a record they own — what do you check? → FLS on the profile/permission sets, then the page layout.
- How do you give one team access to records owned by another? → Sharing rule (owner-based or criteria-based) to a public group/role.
- Profile vs permission set? → One profile per user (baseline) vs many permission sets (additive).
- Can a sharing rule restrict access? → No, it only grants more.