Salesforce profiles have been the foundation of access control since the platform's earliest days. Every user gets one profile; the profile determines what they can see, create, edit, and delete. It is a simple model that works at small scale and becomes progressively more painful as orgs grow — until you have forty custom profiles, each one a slightly different variation of the one before it, and nobody is confident about what any of them actually grant. The Salesforce permission sets vs profiles question has been settled by Salesforce itself: permission sets are the future of access control, and the platform's long-term roadmap is moving away from profile-based configuration entirely. Here is what that means for your org in 2026 and how to make the transition well.
Why Profiles Became a Problem
Profiles accumulate. A new hire needs a slightly different permission than an existing profile provides — clone the nearest profile, make the change, name it "Sales Rep - Extended." Two years later, you have fifteen Sales Rep variants and nobody knows what "Extended" means. The access control model that was supposed to be clear and auditable has become opaque and difficult to maintain.
The deeper problem is that profiles are monolithic. Every setting — object permissions, field-level security, tab visibility, app access, page layout assignment, record type default, login IP ranges — is bundled into one object per user. Changing one setting for one user means either modifying their profile (and affecting everyone on that profile) or creating a new profile variant. Neither option scales.
GDPR and ISO 27001 audits exposed the profile model's weaknesses clearly: auditors want to see that users have the minimum permissions necessary for their role, and that those permissions can be explained and justified. Explaining why a profile was cloned five years ago and has accumulated twenty undocumented permission additions is not a comfortable conversation in an audit.
Permission Sets: The Composable Access Model
Permission sets solve the monolith problem by making access composable. Instead of one large profile that contains everything, you build small, focused permission sets that each grant a specific capability:
Cases_Read— read access to Case objectCases_Edit— create and edit access to Case objectCases_Delete— delete access to Case objectPremium_Support_Features— access to custom features for senior agentsCompliance_Field_Visibility— field-level access to compliance-sensitive fields
A frontline agent gets Cases_Read and Cases_Edit. A senior agent gets all three. A compliance officer gets all three plus Compliance_Field_Visibility. When a user is promoted, you add one permission set. When they leave, you remove all assigned sets — and you have a complete audit trail of exactly what was granted and when.
Permission Set Groups: Managing Complexity at Scale
Permission set groups bundle multiple permission sets into a single assignable unit. Instead of assigning eight individual permission sets to every Sales Manager, you create a Sales_Manager group that includes all eight, and assign the group. When a permission set within the group needs updating, you update it once and all users with the group get the change automatically.
Permission set groups also support muting policies — a way to suppress specific permissions from a permission set within the group context. This is useful when you want to include a broad permission set in a group but exclude specific permissions that are too wide for that role. Muting is a group-level override, not a modification of the underlying permission set, so the same set can be used in other groups without the muting applied.
| Access Model Component | Purpose | Assignable To Users |
|---|---|---|
| Profile | Minimum baseline: licence type, record type defaults, page layouts | Yes (1 per user, required) |
| Permission Set | Specific access grant: object/field/system permissions | Yes (multiple per user) |
| Permission Set Group | Bundle of permission sets for a role | Yes (multiple per user) |
| Muting Policy | Suppress specific permissions within a group | No (attached to group) |
The Compliance Case for Permission Sets
From a GDPR and ISO 27001 perspective, the permission set model is substantially better than the profile model. The principle of least privilege is easier to implement and verify: you can see exactly which permission sets a user holds, read what each one grants, and confirm that the combination is appropriate for the user's role. This is the evidence a data protection officer or an ISO 27001 auditor wants to see.
Temporary access grants — giving a developer production read access for a specific debugging task — can be implemented by temporarily assigning a permission set and revoking it when the task is done. The assignment and revocation are both recorded in Salesforce's setup audit trail, providing an automatic evidence record for the access review.
Field-level masking, as provided by tools like MaskEzee, layers on top of the permission set model to provide graduated field visibility — showing partial data to one permission level, full data to another — without needing to create separate profiles or field-level security configurations for each visibility tier. This is the access control architecture that compliance auditors expect to see in orgs handling personal data.
Role-based field masking on top of your permission architecture
MaskEzee adds graduated field visibility to Salesforce — showing partial PII to frontline agents and full data to compliance officers — directly inside the platform, using your existing permission set structure.
See MaskEzee →Frequently Asked Questions
Is Salesforce deprecating profiles in favour of permission sets?
Salesforce has a long-term roadmap toward retiring legacy profiles. As of 2026, profiles still exist and are required (every user must have exactly one), but Salesforce is progressively removing settings from profiles. New orgs are encouraged to use minimal profiles and manage all access through permission sets and permission set groups.
What is the difference between a permission set and a permission set group?
A permission set grants a specific collection of access controls. A permission set group bundles multiple permission sets into a single assignable unit for a role. Groups also support muting policies to selectively suppress specific permissions within the group context without modifying the underlying permission set.
What should stay in profiles and what should move to permission sets?
Profiles should contain the minimum baseline: user licence type, record type defaults, and page layout assignments. Everything else — object CRUD permissions, field-level security, app access, custom permissions, system permissions — should live in permission sets. Profiles become thin and largely uniform; permission sets carry the functional access.
How do permission sets improve GDPR and compliance posture?
Permission sets make access granular and auditable — you can see exactly what each set grants, confirm the combination is appropriate for the user's role, and provide this as evidence to GDPR or ISO 27001 auditors. Temporary access grants are trackable in the setup audit trail. Least privilege is easier to implement and verify than with broad profiles.
How long does it take to migrate from profiles to permission sets in a mature org?
In a mature org with many custom profiles, expect a two to four week project with adequate testing time. The approach: audit current profiles, map active permissions to logical permission sets, test with representative users, migrate one user group at a time. The migration pays for itself in long-term maintainability and compliance auditability.