🛡️
Security Model for App Builder
The 4 security layers, profiles vs permission sets, OWD, role hierarchy, sharing rules, and practical scenarios.
⏱️ Estimated reading time: 50 minutes
The 4 Security Layers: Overview
Salesforce's security model is a system of progressively more granular layers. Each layer restricts access more precisely.
Security Pyramid (from broadest to most specific):
Layer 1 — Organization Level:
- Login IP Ranges: Restrict which IPs a profile can log in from.
- On Profiles: If the user is OUTSIDE the range, access is BLOCKED completely.
- On Permission Sets: If outside, identity verification is required (but not blocked).
- Login Hours: Restrict what hours login is allowed (per profile).
- Password Policies: Complexity, expiration, password history.
- MFA (Multi-Factor Authentication): Mandatory second authentication factor.
- Session Security: Session expiration time, security levels.
Layer 2 — Object Level (CRUD):
- Profiles and Permission Sets control Create, Read, Update, Delete, and View All / Modify All per object.
- Without Read permission → user doesn't see the object in any context.
- Without Create permission → cannot create records for that object.
Layer 3 — Field Level Security (FLS):
- Controls individual field visibility within an object.
- Two options per field: Visible (can see) and Read-Only (can see but not edit).
- If a field is invisible via FLS, it doesn't appear in: UI, reports, API, list views, or search results.
- FLS is the most definitive control for fields.
Layer 4 — Record Level:
- Controls which specific records each user can see.
- Components: OWD + Role Hierarchy + Sharing Rules + Manual Sharing + Teams.
- Detailed in the following sections.
Fundamental principle (KEY for the exam):
Access is configured from most restrictive to most permissive. Start with restrictive OWD and open with Sharing Rules. You can NEVER restrict more than OWD (except with Restriction Rules, which are an advanced exception).
Security Pyramid (from broadest to most specific):
┌──────────────────────────────────┐
│ 1. ORGANIZATION LEVEL │ ← Who can enter the org
├──────────────────────────────────┤
│ 2. OBJECT LEVEL (CRUD) │ ← What objects they can see
├──────────────────────────────────┤
│ 3. FIELD LEVEL (FLS) │ ← What fields they can see
├──────────────────────────────────┤
│ 4. RECORD LEVEL │ ← What specific records they can see
└──────────────────────────────────┘Layer 1 — Organization Level:
- Login IP Ranges: Restrict which IPs a profile can log in from.
- On Profiles: If the user is OUTSIDE the range, access is BLOCKED completely.
- On Permission Sets: If outside, identity verification is required (but not blocked).
- Login Hours: Restrict what hours login is allowed (per profile).
- Password Policies: Complexity, expiration, password history.
- MFA (Multi-Factor Authentication): Mandatory second authentication factor.
- Session Security: Session expiration time, security levels.
Layer 2 — Object Level (CRUD):
- Profiles and Permission Sets control Create, Read, Update, Delete, and View All / Modify All per object.
- Without Read permission → user doesn't see the object in any context.
- Without Create permission → cannot create records for that object.
Layer 3 — Field Level Security (FLS):
- Controls individual field visibility within an object.
- Two options per field: Visible (can see) and Read-Only (can see but not edit).
- If a field is invisible via FLS, it doesn't appear in: UI, reports, API, list views, or search results.
- FLS is the most definitive control for fields.
Layer 4 — Record Level:
- Controls which specific records each user can see.
- Components: OWD + Role Hierarchy + Sharing Rules + Manual Sharing + Teams.
- Detailed in the following sections.
Fundamental principle (KEY for the exam):
Access is configured from most restrictive to most permissive. Start with restrictive OWD and open with Sharing Rules. You can NEVER restrict more than OWD (except with Restriction Rules, which are an advanced exception).
🎯 Key Points
- ✓ 4 layers: Organization → Object (CRUD) → Field (FLS) → Record
- ✓ Access is OPENED from bottom to top: restrictive OWD → Sharing Rules to open
- ✓ FLS hides fields in ALL contexts: UI, API, reports, searches
- ✓ Login IP Ranges on Profiles BLOCK; on Permission Sets they only require verification
- ✓ You can NEVER restrict more than OWD using standard Sharing Rules
Profiles vs Permission Sets: Detailed Comparison
Profiles:
Each user has exactly ONE profile. The profile defines the user's BASE permissions.
What a Profile controls:
- CRUD per object: Create, Read, Update, Delete, View All, Modify All.
- Field-Level Security: Field visibility and editability.
- System Permissions: System permissions (API Enabled, View Setup, Create Reports, Manage Users, etc.).
- Login Hours: Allowed access schedule.
- Login IP Ranges: Allowed IP ranges (BLOCKS if outside).
- Default Record Type: Default Record Type per object.
- Page Layout Assignment: Combination with Record Type.
- App Visibility: Which Lightning Apps the user can see.
- Tab Settings: Tab visibility (Default On, Default Off, Hidden).
Standard Profile types:
- System Administrator: All permissions. Cannot be modified or deleted.
- Standard User: Basic read/write permissions.
- Standard Platform User: For platform users (without Sales/Service).
- Minimum Access - Salesforce: Minimum access, ideal as base + Permission Sets.
- Read Only: Read-only on all objects.
Salesforce recommends: Use the "Minimum Access" profile as a base and add permissions with Permission Sets. This is called the "least privilege" model.
Permission Sets:
A user can have multiple Permission Sets. They only ADD permissions, never subtract.
What a Permission Set controls:
- All the same permissions as a Profile (CRUD, FLS, System Permissions).
- Login IP Ranges (with different behavior: requests verification, doesn't block).
- Object permissions, Field permissions, System permissions, App permissions.
Advantages over Profiles:
- Multiple PS can be assigned to a user.
- They are cumulative (add permissions).
- Allow giving granular permissions without creating multiple profiles.
- Easier to maintain: one PS can serve multiple profiles.
Permission Set Groups:
- Group multiple Permission Sets into a single assignable package.
- Simplify management: instead of assigning 5 PS individually, assign 1 group.
- Muting Permission Set: A special PS can be included within the group that disables specific permissions from other PS in the group. It's the only way to "subtract" permissions within a group.
Exam comparison table:
Each user has exactly ONE profile. The profile defines the user's BASE permissions.
What a Profile controls:
- CRUD per object: Create, Read, Update, Delete, View All, Modify All.
- Field-Level Security: Field visibility and editability.
- System Permissions: System permissions (API Enabled, View Setup, Create Reports, Manage Users, etc.).
- Login Hours: Allowed access schedule.
- Login IP Ranges: Allowed IP ranges (BLOCKS if outside).
- Default Record Type: Default Record Type per object.
- Page Layout Assignment: Combination with Record Type.
- App Visibility: Which Lightning Apps the user can see.
- Tab Settings: Tab visibility (Default On, Default Off, Hidden).
Standard Profile types:
- System Administrator: All permissions. Cannot be modified or deleted.
- Standard User: Basic read/write permissions.
- Standard Platform User: For platform users (without Sales/Service).
- Minimum Access - Salesforce: Minimum access, ideal as base + Permission Sets.
- Read Only: Read-only on all objects.
Salesforce recommends: Use the "Minimum Access" profile as a base and add permissions with Permission Sets. This is called the "least privilege" model.
Permission Sets:
A user can have multiple Permission Sets. They only ADD permissions, never subtract.
What a Permission Set controls:
- All the same permissions as a Profile (CRUD, FLS, System Permissions).
- Login IP Ranges (with different behavior: requests verification, doesn't block).
- Object permissions, Field permissions, System permissions, App permissions.
Advantages over Profiles:
- Multiple PS can be assigned to a user.
- They are cumulative (add permissions).
- Allow giving granular permissions without creating multiple profiles.
- Easier to maintain: one PS can serve multiple profiles.
Permission Set Groups:
- Group multiple Permission Sets into a single assignable package.
- Simplify management: instead of assigning 5 PS individually, assign 1 group.
- Muting Permission Set: A special PS can be included within the group that disables specific permissions from other PS in the group. It's the only way to "subtract" permissions within a group.
Exam comparison table:
| Feature | Profile | Permission Set | PS Group |
|---|---|---|---|
| Assignment per user | 1 mandatory | 0 or more | 0 or more |
| Adds permissions | ✅ | ✅ | ✅ |
| Removes permissions | ❌ | ❌ | ✅ (Muting PS) |
| Login Hours | ✅ | ❌ | ❌ |
| Login IP Ranges | ✅ (blocks) | ✅ (verifies) | ❌ |
| Default Record Type | ✅ | ✅ | ❌ |
| Page Layout Assignment | ✅ | ❌ | ❌ |
🎯 Key Points
- ✓ Each user has exactly 1 Profile + 0 or more Permission Sets
- ✓ Permission Sets only ADD permissions, never subtract (except Muting PS in Groups)
- ✓ Recommended model: Minimum Access Profile + granular Permission Sets
- ✓ Login Hours are ONLY configured on Profiles, NOT Permission Sets
- ✓ Page Layout Assignment is ONLY controlled from the Profile (not PS)
- ✓ Permission Set Groups simplify assignment by bundling multiple PS
Record Level Security: OWD, Role Hierarchy, and Sharing Rules
Record-level security determines which specific records each user can see, even if they have CRUD permissions on the object.
Organization-Wide Defaults (OWD) — The Baseline:
Define the DEFAULT access level all users have for each object.
Golden rule: If ANY user group needs restricted access to an object's records → OWD must be Private (or Public Read Only). Then open access with sharing tools.
If OWD is Public Read/Write, you DON'T need Sharing Rules since everyone can see and edit everything.
Role Hierarchy:
- Users in higher roles automatically inherit access to records of users in lower roles.
- Example: VP of Sales can see all records from their Sales Managers, who can see records from their Sales Reps.
- Role hierarchy is NOT the same as the org chart (reporting hierarchy on User record). Role hierarchy is for DATA ACCESS.
- Grant Access Using Hierarchies: Per-object setting that allows disabling role hierarchy inheritance for custom objects. For standard objects, it's always active.
Sharing Rules:
Open access beyond OWD for specific user groups.
Two types of Sharing Rules:
1. Ownership-Based Sharing Rules:
- "Records owned by Group A users are visible to Group B users."
- Based on who owns the record.
- Example: Opportunity records owned by
2. Criteria-Based Sharing Rules:
- "Records meeting SPECIFIC CRITERIA are visible to a group."
- Based on record field values (not ownership).
- Example: All Cases where
- More flexible than Ownership-Based.
Shared with options: Public Groups, Roles, Roles & Subordinates, Queues.
Manual Sharing:
- The record owner (or admin) can share a specific record with users, roles, or public groups.
- Done by clicking the 'Sharing' button on the record.
- It's temporary and removed if the record owner changes.
Account Teams / Opportunity Teams / Case Teams:
- Allow assigning a team of users to a specific record with different access levels.
- Configured as a role type within the team (e.g., Account Manager, Executive Sponsor).
- Each team member can have Read Only or Read/Write access.
Public Groups:
- Containers of users, roles, and/or other public groups that simplify Sharing Rule assignment.
- Example: create an
Queues:
- Special user groups that can own records.
- Records in a Queue appear in a shared List View.
- Only available for: Leads, Cases, Custom Objects, and some standard objects.
- Use case: assignment of incoming Leads/Cases to an agent pool.
Organization-Wide Defaults (OWD) — The Baseline:
Define the DEFAULT access level all users have for each object.
| OWD Setting | Meaning |
|---|---|
| Private | Only the owner and hierarchy superiors can see their records |
| Public Read Only | Everyone can see, but only the owner can edit |
| Public Read/Write | Everyone can see AND edit all records |
| Public Read/Write/Transfer | Everyone can see, edit, and transfer (Leads and Cases only) |
| Controlled by Parent | Inherits access from the parent object (Master-Detail only) |
Golden rule: If ANY user group needs restricted access to an object's records → OWD must be Private (or Public Read Only). Then open access with sharing tools.
If OWD is Public Read/Write, you DON'T need Sharing Rules since everyone can see and edit everything.
Role Hierarchy:
- Users in higher roles automatically inherit access to records of users in lower roles.
- Example: VP of Sales can see all records from their Sales Managers, who can see records from their Sales Reps.
- Role hierarchy is NOT the same as the org chart (reporting hierarchy on User record). Role hierarchy is for DATA ACCESS.
- Grant Access Using Hierarchies: Per-object setting that allows disabling role hierarchy inheritance for custom objects. For standard objects, it's always active.
Sharing Rules:
Open access beyond OWD for specific user groups.
Two types of Sharing Rules:
1. Ownership-Based Sharing Rules:
- "Records owned by Group A users are visible to Group B users."
- Based on who owns the record.
- Example: Opportunity records owned by
Sales Team West are shared with Sales Managers.2. Criteria-Based Sharing Rules:
- "Records meeting SPECIFIC CRITERIA are visible to a group."
- Based on record field values (not ownership).
- Example: All Cases where
Priority = 'Critical' are shared with Executive Team.- More flexible than Ownership-Based.
Shared with options: Public Groups, Roles, Roles & Subordinates, Queues.
Manual Sharing:
- The record owner (or admin) can share a specific record with users, roles, or public groups.
- Done by clicking the 'Sharing' button on the record.
- It's temporary and removed if the record owner changes.
Account Teams / Opportunity Teams / Case Teams:
- Allow assigning a team of users to a specific record with different access levels.
- Configured as a role type within the team (e.g., Account Manager, Executive Sponsor).
- Each team member can have Read Only or Read/Write access.
Public Groups:
- Containers of users, roles, and/or other public groups that simplify Sharing Rule assignment.
- Example: create an
Executive_Team group including CEO, CFO, CTO roles, then share records with that group.Queues:
- Special user groups that can own records.
- Records in a Queue appear in a shared List View.
- Only available for: Leads, Cases, Custom Objects, and some standard objects.
- Use case: assignment of incoming Leads/Cases to an agent pool.
🎯 Key Points
- ✓ OWD is the baseline: Private = most restrictive; Public Read/Write = most open
- ✓ If ANY group needs restricted access → OWD should be Private
- ✓ Role Hierarchy: higher roles inherit access to lower roles' records
- ✓ 2 types of Sharing Rules: Ownership-Based (by owner) and Criteria-Based (by field values)
- ✓ Manual Sharing is automatically removed when record owner changes
- ✓ Grant Access Using Hierarchies can be disabled for Custom Objects but NOT Standard Objects
- ✓ Queues can own records (Leads, Cases, Custom Objects)
Practical Security Scenarios (Exam-Style)
The PAB exam presents scenarios where you must choose the correct security solution. Here are the most common patterns:
Scenario 1: "Salespeople should only see their own Opportunities"
- Solution: Opportunity OWD = Private.
- Managers will see their subordinates' via Role Hierarchy.
- No additional Sharing Rules needed.
Scenario 2: "Marketing team needs to see, but not edit, all Opportunities"
- Solution: Opportunity OWD = Private (so salespeople don't see each other's).
- Sharing Rule: Share all Opportunities with Public Group 'Marketing' with Read Only access.
Scenario 3: "A user cannot see a specific field in UI or reports"
- Solution: Field-Level Security (FLS). Make the field invisible for the user's profile.
- FLS hides the field in ALL contexts.
Scenario 4: "A user can see the Account object but cannot create new records"
- Solution: In the Profile or Permission Set, give Read but NOT Create permission for Account.
Scenario 5: "Critical Cases must be visible to the executive team"
- Solution: Criteria-Based Sharing Rule: Where Priority = 'Critical', share with 'Executive Team' group with Read/Write.
Scenario 6: "Need to give additional permissions to a group of users without creating a new profile"
- Solution: Permission Set or Permission Set Group.
- Create a PS with additional permissions and assign to users.
Scenario 7: "A user sees records on the object but a field appears blank when it has data"
- Probable cause: FLS — the field isn't visible for the user's profile.
- Or: the field may be excluded from the assigned Page Layout.
Scenario 8: "A record owner needs to share a specific case with a colleague temporarily"
- Solution: Manual Sharing — click 'Sharing' on the record and add the user.
Scenario 9: "Incoming Leads should be distributed among a group of agents"
- Solution: Queue — create a Queue with agents. Leads are assigned to the Queue and agents pick them from the shared list.
Scenario 10: "An administrator wants to apply the least privilege principle"
- Solution: Assign the Minimum Access - Salesforce profile to all users and use Permission Sets to add only necessary permissions.
Quick decision table:
Scenario 1: "Salespeople should only see their own Opportunities"
- Solution: Opportunity OWD = Private.
- Managers will see their subordinates' via Role Hierarchy.
- No additional Sharing Rules needed.
Scenario 2: "Marketing team needs to see, but not edit, all Opportunities"
- Solution: Opportunity OWD = Private (so salespeople don't see each other's).
- Sharing Rule: Share all Opportunities with Public Group 'Marketing' with Read Only access.
Scenario 3: "A user cannot see a specific field in UI or reports"
- Solution: Field-Level Security (FLS). Make the field invisible for the user's profile.
- FLS hides the field in ALL contexts.
Scenario 4: "A user can see the Account object but cannot create new records"
- Solution: In the Profile or Permission Set, give Read but NOT Create permission for Account.
Scenario 5: "Critical Cases must be visible to the executive team"
- Solution: Criteria-Based Sharing Rule: Where Priority = 'Critical', share with 'Executive Team' group with Read/Write.
Scenario 6: "Need to give additional permissions to a group of users without creating a new profile"
- Solution: Permission Set or Permission Set Group.
- Create a PS with additional permissions and assign to users.
Scenario 7: "A user sees records on the object but a field appears blank when it has data"
- Probable cause: FLS — the field isn't visible for the user's profile.
- Or: the field may be excluded from the assigned Page Layout.
Scenario 8: "A record owner needs to share a specific case with a colleague temporarily"
- Solution: Manual Sharing — click 'Sharing' on the record and add the user.
Scenario 9: "Incoming Leads should be distributed among a group of agents"
- Solution: Queue — create a Queue with agents. Leads are assigned to the Queue and agents pick them from the shared list.
Scenario 10: "An administrator wants to apply the least privilege principle"
- Solution: Assign the Minimum Access - Salesforce profile to all users and use Permission Sets to add only necessary permissions.
Quick decision table:
| Need | Tool |
|---|---|
| Control which objects a user can see | Profile / Permission Set (CRUD) |
| Hide fields in all contexts | Field-Level Security (FLS) |
| Limit access to specific records | OWD + Sharing Rules |
| Additional permissions for user group | Permission Set / PS Group |
| Share a specific record temporarily | Manual Sharing |
| Distribute records among an agent pool | Queue |
| Login schedule restrictions | Profile (Login Hours) |
| IP restrictions | Profile (blocks) or PS (verifies) |
🎯 Key Points
- ✓ If you need to restrict records → start with Private OWD + Sharing Rules to open
- ✓ If a field is not visible → think FLS first, then Page Layout
- ✓ For additional permissions without a new profile → Permission Set or PS Group
- ✓ Criteria-Based Sharing: shares by field values (more flexible than Ownership-Based)
- ✓ Manual Sharing is temporary and disappears when owner changes
- ✓ Queues for distributing Leads/Cases among an agent team