🛡️
The Salesforce Security Model: Access Layers
Mastering OWD, role hierarchy, profiles, permission sets, and sharing rules.
⏱️ Estimated reading time: 45 minutes
The Security Pyramid
Access in Salesforce is managed across three primary levels. Imagine a pyramid:
1. Object (Base Level): Can the user see the 'Accounts' object? (Profiles/Permission Sets).
2. Field: If they see the object, can they see the 'Salary' field? (Field-Level Security).
3. Record (Top Level): If they see the object and field, can they see the specific record for 'Customer A'? (OWD, Role Hierarchy, Sharing Rules).
1. Object (Base Level): Can the user see the 'Accounts' object? (Profiles/Permission Sets).
2. Field: If they see the object, can they see the 'Salary' field? (Field-Level Security).
3. Record (Top Level): If they see the object and field, can they see the specific record for 'Customer A'? (OWD, Role Hierarchy, Sharing Rules).
🎯 Key Points
- ✓ Profiles and Permission Sets determine what a user can do (CRED: Create, Read, Edit, Delete)
- ✓ Record-level access determines which specific data they can see
- ✓ Golden Rule: Object-level permissions ALWAYS win. If I don't have object access, it doesn't matter if someone shares a record with me.
Object and Field Access (Profiles and Permission Sets)
Profiles: The baseline. Every user has one. They define object permissions, visible apps, login hours, and IPs.
Permission Sets: Extend access. Used to grant specific permissions without creating new profiles.
Field-Level Security (FLS): The most restrictive form of security. If a field is hidden via FLS, the user won't see it in reports, list views, or search results, even if they have record access.
Permission Sets: Extend access. Used to grant specific permissions without creating new profiles.
Field-Level Security (FLS): The most restrictive form of security. If a field is hidden via FLS, the user won't see it in reports, list views, or search results, even if they have record access.
🎯 Key Points
- ✓ Permission Sets can only GRANT access, never restrict it
- ✓ Standard Profiles cannot be edited (you must clone them)
- ✓ FLS overrides Page Layouts: if a field is required on the layout but the user lacks edit permission in FLS, they cannot edit it.
Record-Level 1: Organization-Wide Defaults (OWD)
OWD defines the baseline access users have to records they DO NOT own.
- Private: Only the owner sees the record.
- Public Read-Only: Everyone sees, only owner edits.
- Public Read/Write: Everyone sees and edits.
- Controlled by Parent: (Only for children in Master-Detail). Security depends on the parent object.
- Private: Only the owner sees the record.
- Public Read-Only: Everyone sees, only owner edits.
- Public Read/Write: Everyone sees and edits.
- Controlled by Parent: (Only for children in Master-Detail). Security depends on the parent object.
🎯 Key Points
- ✓ OWD is the only way to RESTRICT record access
- ✓ OWD should be set to the most restrictive level required by the business
- ✓ For custom objects, you can uncheck 'Grant Access Using Hierarchies' to stop managers from seeing subordinates' records (this cannot be disabled for standard objects).
Record-Level 2 & 3: Role Hierarchy and Sharing Rules
Role Hierarchy (Vertical Access): Allows users at higher levels of the hierarchy to see records owned by subordinates. It does not have to match the company's org chart.
Sharing Rules (Horizontal Access): Automatic exceptions. They allow sharing records between public groups, roles, or territories based on criteria (e.g., 'Share all Pharmacy type Accounts with the Madrid Team').
Sharing Rules (Horizontal Access): Automatic exceptions. They allow sharing records between public groups, roles, or territories based on criteria (e.g., 'Share all Pharmacy type Accounts with the Madrid Team').
🎯 Key Points
- ✓ Sharing Rules are only used when OWD is Private or Public Read-Only
- ✓ There are two types of Sharing Rules: Owner-based and Criteria-based
- ✓ Roles determine which records you see; Profiles determine what you do with them.
Record-Level 4: Manual Sharing and Teams
Manual Sharing: Allows a record owner to share an individual record with another user. In Lightning, this is done via the 'Sharing' button.
Account/Opportunity/Case Teams: Allows a group of users to collaborate on a specific record. The admin must enable teams and define team roles.
Account/Opportunity/Case Teams: Allows a group of users to collaborate on a specific record. The admin must enable teams and define team roles.
🎯 Key Points
- ✓ To share manually, the user must be the Owner, a Manager in the hierarchy, or an Admin
- ✓ Teams facilitate reporting on who collaborated on a successful sale
- ✓ If the record owner changes, Manual Sharing is automatically removed.
Monitoring: Health Check and Auditing
Health Check: A tool that scans security settings and assigns a score (0-100%). It identifies risks like weak passwords or non-expiring sessions.
Setup Audit Trail: Tracks changes made by admins in the last 180 days (who changed a profile, who created a field).
Setup Audit Trail: Tracks changes made by admins in the last 180 days (who changed a profile, who created a field).
🎯 Key Points
- ✓ Login History: Shows the last 6 months of login attempts (successes and failures)
- ✓ Field Audit Trail: Tracks field value history (requires add-on license for more than 18 months)
- ✓ Password Policies can be set at the Org level or Profile level (Profile level wins).