The Salesforce Permission Model

Permissions Are Architecture, Not Administration

In most Salesforce implementations, the permission model evolves organically. A user can't see a field — grant FLS. A user can't access certain records — add a sharing rule. Repeat for five years, and you have a permission model that nobody fully understands and that security auditors find indefensible. This is permission model drift, and it's the norm rather than the exception in mature Salesforce orgs.

The alternative is treating permissions as architecture from the start: defining the permission model before build, designing it from the principle of least privilege, and treating permission changes as governed changes rather than routine support tickets. The implementation is identical — you're using the same Salesforce configuration tools — but the intent and the outcome are entirely different.

The Five Layers of Salesforce Access Control

Salesforce access control operates at five distinct layers. Understanding each layer — what it controls, how it interacts with the layers around it, and when it takes precedence — is the foundation of permission architecture.

Layer 1: Object-Level Security (OLS)

OLS controls whether a user can see, create, edit, or delete records of a given object type. Configured via Profiles and Permission Sets. This is the broadest layer — if a user doesn't have Read access to Accounts at the object level, no amount of sharing rules will make Account records visible. OLS is the architectural gating layer.

Layer 2: Field-Level Security (FLS)

FLS controls visibility and editability of individual fields on objects where the user has object access. A user might have Read access to Accounts but not be able to see the Annual Revenue field. FLS is configured per profile/permission set, per object, per field. In large orgs with hundreds of custom fields, FLS management is a significant ongoing governance burden.

Layer 3: Record-Level Security (Sharing)

Even with object access and field access, a user can only see records that have been shared with them. Record-level access is controlled by OWD, Role Hierarchy, Sharing Rules, Manual Sharing, and Apex Managed Sharing. This is the most complex layer and the one that generates the most support tickets in operational orgs.

Layer 4: UI Layer Security (Page Layouts, Lightning App Builder)

Page layouts and Lightning pages can show or hide fields and components. This is NOT a security layer — it's a presentation layer. A user who can see a field via FLS can access that field's value via API even if it's hidden from their page layout. Never rely on page layout hiding as a security control.

Layer 5: System-Level Permissions

System permissions control platform-level capabilities: "View All Data," "Modify All Data," "Manage Users," "API Enabled." These bypass record-level sharing entirely. A user with "View All Data" can see every record in the org regardless of OWD and sharing rules. System permissions are the highest-risk permissions in any org and should be audited regularly.

OWD and Sharing Architecture: The Opening-Up Principle

Org-Wide Defaults define the most restrictive baseline sharing posture for each object. The fundamental principle: sharing can only open up from OWD, never lock down. If OWD for Accounts is "Private," no user can see another user's Accounts by default. You then selectively open access via Role Hierarchy, Sharing Rules, or Apex Managed Sharing. You cannot make individual records more restrictive than OWD.

This is the architectural reason to set OWD conservatively: "Private" or "Public Read Only" for sensitive objects, never "Public Read/Write" for objects containing regulated or confidential data. Opening up is straightforward; locking down after the fact requires rethinking your entire sharing architecture.

-- SOQL audit: find users who can see records they shouldn't
-- via the ObjectPermissions and FieldPermissions objects

-- Check which Permission Sets grant Edit on a sensitive object
SELECT Parent.Label, Parent.Name
FROM   ObjectPermissions
WHERE  SObjectType = 'FinancialAccount__c'
AND    PermissionsEdit = true
ORDER BY Parent.Label

-- Check sharing: who has access to a specific record
-- Use RecordAccess (supported in API v25+)
SELECT RecordId, HasReadAccess, HasEditAccess, MaxAccessLevel
FROM   UserRecordAccess
WHERE  UserId = '005XXXX'
AND    RecordId IN :recordIds

Role Hierarchy and Its Misconceptions

The Role Hierarchy grants record access upward — a manager in the hierarchy automatically sees records owned by their direct and indirect reports. This is not a management reporting structure; it's a data access escalation path. In flat or matrix organisations, the Role Hierarchy often ends up misconfigured because administrators try to model org chart relationships instead of data access patterns. Design the Role Hierarchy around data access needs, not reporting lines.

Profiles vs Permission Sets: The Migration That's Now Mandatory

Salesforce has been pushing teams toward a Permission Set-centric model for years and has now set a concrete deprecation path for Profiles. As of 2026, Salesforce has signalled that the Profile-based access model will be deprecated in a future release — the exact timeline has shifted, but the direction is clear and unambiguous.

The Permission Set model is architecturally cleaner: instead of one large Profile per user type that contains all permissions, you compose a user's access from multiple targeted Permission Sets. A user might have "Sales Standard Access" (PS1) + "Contract Management" (PS2) + "Report Builder" (PS3). This composable model allows more granular access design and makes the "least privilege" principle easier to implement.

The Migration Challenge

Most orgs have dozens of Profiles, each containing hundreds of permissions accumulated over years. Migrating to Permission Sets requires decomposing each Profile into its constituent permission needs and rebuilding them as a Permission Set library. This is not technically complex — it's administratively intensive and requires a clear understanding of why each permission exists, which is often undocumented.

Principle of Least Privilege in Salesforce

The Principle of Least Privilege states that a user should have exactly the access needed to perform their function — no more. Implementing this in Salesforce requires three design decisions: what objects the user needs (OLS), what fields on those objects (FLS), and which records (sharing). These decisions should be made from the user's job function, not from convenience.

In practice, least privilege in Salesforce fails most often in two places. First, in API integration users: integration accounts are frequently granted "Modify All Data" or "System Administrator" profile because it's the path of least resistance when setting up an integration. This is a significant security risk — any compromise of the integration credentials grants full org access. Integration users should have the minimum permissions needed for their specific integration function.

Second, in "temporary" access grants that become permanent. A user is given elevated access "just for this project" and the access is never revoked. In a mature org, these accumulated temporary grants create a permission model that no longer reflects any intentional design. Permission set assignment reviews — automated via Flow or manual via governance — should be a regular part of your operational security posture.

Auditing Your Permission Model

A permission model audit should answer three questions: who has access to sensitive data (sensitive objects, fields, and records), who has elevated system permissions (View All, Modify All, Manage Users), and are there over-permissioned integration users or inactive users who still have licences and access.

Salesforce provides audit tooling via the Permission Analyser (Setup UI), the User Access and Permissions Assistant (UAPA), and the SOQL-queryable permission objects (ObjectPermissions, FieldPermissions, PermissionSet, PermissionSetAssignment). For organisations with Shield, Event Monitoring provides audit logs of what users actually accessed, not just what they're permitted to access — the gap between "permitted" and "actually accessed" is often revealing.

What Good Permission Architecture Looks Like

A well-designed Salesforce permission model has three characteristics. First, it is documented: for every Permission Set, there is a documented owner, a documented purpose, and a review date. "Admin created it in 2021 to fix something" is not documentation. Second, it is minimal: each user has the minimum access required. When access is granted temporarily, there is a process to revoke it. Third, it is auditable: you can answer the question "who can see our customer's financial data?" in under five minutes using SOQL queries against the permission objects.

Most Salesforce orgs fail on all three. The remediation path is not a one-time project — it's a governance programme. Start with a permission audit to understand current state, define the target permission architecture based on job function analysis, migrate in phases starting with the most sensitive objects, and establish ongoing governance to prevent drift from recurring.