Permissions: Quick Reference

Fast-track reference for profiles, permission sets, FLS, and the modern permission model. The board tests specifically whether you understand that page layouts are NOT security. Know the difference cold.

The Modern Permission Model

The recommended architecture for enterprise Salesforce deployments:

Figure 1. The modern permission model keeps the profile nearly empty and delegates all meaningful access to Permission Set Groups. Atomic Permission Sets can be reused across roles, and Muting Permission Sets handle exceptions within a PSG without touching the profile or other assignments.

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 January 2024, the hard enforcement date was removed, but Salesforce still recommends a permission set-led model. Future investment goes entirely 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 matters: if the profile grants it, muting cannot take it away.

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. Reserve 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 self-governing designs.

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