Permissions: Quick Reference
Fast-track reference for profiles, permission sets, FLS, and the modern permission model. The board specifically tests whether you understand that page layouts are NOT security — know the difference cold.
The Modern Permission Model
The recommended architecture for any enterprise Salesforce deployment:
flowchart TD
MAP["Minimum Access Profile\n(almost no permissions)"]
MAP --> PSG1["PSG: Sales Rep"]
MAP --> PSG2["PSG: Sales Manager"]
MAP --> PSG3["PSG: Service Agent"]
PSG1 --> PS1["PS: Read Accounts"]
PSG1 --> PS2["PS: Write Opportunities"]
PSG2 --> PS1
PSG2 --> PS2
PSG2 --> PS3["PS: Run Forecasts"]
PSG2 -.->|Mute| M1["Mute: No Delete Opp"]
PSG3 --> PS1
PSG3 --> PS4["PS: Write Cases"]
style MAP fill:#c62828,color:#fff
style PSG1 fill:#1565c0,color:#fff
style PSG2 fill:#1565c0,color:#fff
style PSG3 fill:#1565c0,color:#fff
style M1 fill:#e65100,color:#fff
Pattern: Minimum Access Profile —> Permission Set Groups (represent business roles) —> Atomic Permission Sets (one function each) —> Muting Permission Sets (exceptions)
Profile Retirement Timeline
Profiles Are Changing
Salesforce announced permissions on profiles would reach end-of-life in Spring ‘26. As of the announcement in January 2024, the hard enforcement date was removed, but Salesforce still recommends a permission set-led model. All future investment goes into Permission Sets and PSGs. Start migrating now.
| What Stays on Profiles | What Moves to Permission Sets |
|---|---|
| Page layout assignments | Object permissions (CRUD) |
| Record type defaults | Field-level security |
| Login hours/IP ranges | System permissions |
| Default app assignment | Apex class / VF page access |
| User license association | Tab visibility |
Permission Evaluation Order
Salesforce evaluates permissions cumulatively from all sources:
| Source | How It Combines |
|---|---|
| Profile | Baseline permissions (keep minimal) |
| Permission Sets (individually assigned) | Additive on top of profile |
| Permission Set Groups | Additive; bundles multiple PS |
| Muting Permission Sets | Subtractive WITHIN the PSG only |
Muting Limitation
Muting Permission Sets can only mute permissions within their own Permission Set Group. They CANNOT mute permissions from the profile or from individually assigned Permission Sets. This is why Minimum Access Profile is critical — if the profile grants it, you cannot take it away with muting.
CRUD + View All / Modify All
| Permission | What It Does | Bypasses Sharing? |
|---|---|---|
| Create | Insert new records | No |
| Read | View records (subject to sharing) | No |
| Edit | Update existing records | No |
| Delete | Delete records | No |
| View All | See ALL records regardless of sharing | YES |
| Modify All | Edit/Delete/Transfer ALL records | YES |
View All / Modify All
These bypass the ENTIRE sharing model — OWD, role hierarchy, sharing rules, everything. The board will question any design that relies on View All / Modify All. Only use for data stewards, compliance officers, or dedicated integration users with clear justification.
FLS: The True Security Boundary
| Aspect | Field-Level Security | Page Layout |
|---|---|---|
| Enforced at | API + UI (everywhere) | UI only |
| Can user see via API? | Only if FLS grants access | Yes (if FLS allows) |
| Can user see in reports? | Only if FLS grants access | Yes (if FLS allows) |
| True security? | YES | NO |
| Configured via | Profile or Permission Set | Profile + Record Type |
Page Layouts Are NOT Security
Removing a field from a page layout does NOT prevent access. Users can still see it via reports, list views, API queries, and custom UIs. Only FLS controls true field-level access. The board specifically tests this.
FLS Settings
| Setting | User Sees Field | User Edits Field |
|---|---|---|
| Visible + Editable | Yes | Yes |
| Visible + Read Only | Yes | No |
| Hidden | No | No |
Best practice: Default fields to hidden, then grant visibility through Permission Sets per user type.
Permission Set Design Rules
| Rule | Example |
|---|---|
| One concern per PS | ”Sales: Create Quotes” not “Sales User Everything” |
| Name descriptively | Include functional area + permission granted |
| Never duplicate profile | PS are additive; do not repeat what profile grants |
| Use PSG for role bundles | PSG = “Sales Manager”; PS = individual capabilities |
| Document the purpose | Every PS needs a clear description |
Permission Set Assignment Methods
| Method | Use Case | Automation |
|---|---|---|
| Manual | Ad hoc, small scale | Admin assigns in Setup |
| Permission Set Group | Role-based bulk assignment | Assign PSG to users |
| Flow-based | Dynamic, event-driven | Flow assigns/removes on criteria |
| Apex-based | Integration-driven provisioning | Code assigns during user creation |
| Assignment Expiration | Temporary access | Auto-expires on specified date |
Permission Set Categories
| Category | Granularity | Example |
|---|---|---|
| Function-based | Fine (one action) | “Create Quotes” |
| Feature-based | Medium (platform feature) | “Einstein Analytics User” |
| Integration-based | Fine (specific integration) | “API: Order Sync Service” |
| Temporary | Time-limited | ”Q4 Campaign Access” (use expiration) |
Tab Visibility vs Object Access
| Control | Security? | What It Does |
|---|---|---|
| Tab visibility | NO | Controls whether tab appears in navigation |
| Object permissions | YES | Controls CRUD on the object |
| FLS | YES | Controls field access |
| Page layout | NO | Controls UI display only |
Hiding a tab does NOT prevent access to records. Users can still reach them via search, related lists, reports, and direct URLs.
Anti-Patterns the Board Tests
| Anti-Pattern | Why It Fails | Correct Approach |
|---|---|---|
| Cloning profiles for each role | Profile sprawl; impossible to audit | Minimum Access + PSGs |
| Managing FLS on profiles | Affects all users on that profile | Manage FLS via Permission Sets |
| Page layouts to “hide” fields | API/reports bypass page layouts | Use FLS |
| System Admin profile for integrations | Full admin access, no audit trail | Integration user + minimum PS |
| ”Modify All Data” as shortcut | Bypasses all security | Grant specific object permissions |
| Standard profiles in production | Built-in permissions cannot be removed | Always use custom profiles |
Scenario 1: Minimum Access Rollout
Situation: Insurance company migrating from 25 cloned profiles to a modern permission model. 3,000 users across 8 business functions. Current state: FLS managed on profiles, permission drift everywhere, no audit trail.
What you’d present:
- Create one custom Minimum Access Profile (no object permissions, all fields hidden)
- Design 8 Permission Set Groups (one per business function: Underwriter, Claims Adjuster, Agent, etc.)
- Decompose into ~20 atomic Permission Sets (Read Policies, Write Claims, Run Actuarial Reports, etc.)
- Muting PS for exceptions: Claims Managers get Write Claims but not Delete Claims
- Use User Access Policies to automate migration (match users by old profile, assign new PSG)
- Phased rollout: one business function at a time, validate with test users at each step
Why not keep profiles: 25 profiles with overlapping permissions are unauditable. Any change must be replicated across all profile clones. The PSG model lets you change one Permission Set and it flows to all groups that include it.
Scenario 2: FLS for Regulated Data
Situation: Pharmaceutical company. Sales reps see Account and Contact data. Compliance team needs a “Compliance Risk Score” field on Accounts that reps must NEVER see — not in UI, not in reports, not via API. SOX audit requirement.
What you’d present:
- Compliance Risk Score field: FLS = Hidden on Sales Rep Permission Set
- FLS = Visible + Read Only on Compliance Analyst Permission Set
- FLS = Visible + Editable on Compliance Manager Permission Set
- Do NOT rely on page layout removal (API access would expose the field)
- Verify: create test user with Sales Rep PS, confirm field is invisible in reports, list views, and API queries
- Apex code referencing this field must use USER_MODE or stripInaccessible() to respect FLS
Why FLS and not page layout: SOX audit requires provable field-level security enforcement. Page layout removal is cosmetic — the field remains accessible via API, reports, and list views. Only FLS provides auditable, enforceable access control.
Scenario 3: Temporary Elevated Access
Situation: During month-end close, Finance analysts need Delete access on Journal Entry records for 3 days. Normally they only have Read/Edit. No permanent elevation allowed.
What you’d present:
- Create Permission Set: “Finance: Delete Journal Entries” (Delete permission on Journal Entry object)
- Use Permission Set Assignment Expiration — set to expire 3 days after assignment
- Assignment triggered by manager approval via Flow (approval process —> PS assignment with expiration)
- Audit trail: PS assignment history shows who had elevated access and when
- Alternative considered: Session-Based Permission Sets (rejected — requires re-authentication step that disrupts workflow)
Why Assignment Expiration: Auto-revokes after the specified date. No manual cleanup needed. Full audit trail of when access was granted and removed. The board values designs that are self-governing.
Deep Dive References
- Field & Object Security: Full Deep Dive
- Security Decision Guides: Permission Model Architecture
- Security Best Practices: Permission Anti-Patterns
- Programmatic Security: FLS Enforcement in Apex
Sources
- Salesforce Help: Permission Sets
- Salesforce Help: Permission Set Groups
- Salesforce Help: Field-Level Security
- Salesforce Help: Muting Permission Sets
- Salesforce Ben: Profile Permissions Retirement Updates
- Salesforce Architects: Permissions Decision Guide
- DESelect: Salesforce Roles vs Profiles — Complete 2026 Guide