Permission Sets vs Profiles: The Migration That Never Ends

Why Profiles Are Being Retired

Profiles have been the Salesforce security model for 20 years. Every user has exactly one profile, and that profile controls object permissions, field permissions, record type access, page layout assignments, and system permissions. The problem is that profiles are monolithic — you cannot partially assign them, and every change to a profile affects every user on that profile.

This design creates an antipattern that appears in virtually every enterprise org: profile proliferation. When one user needs a slightly different set of permissions from their colleagues, a new profile is created. Enterprise orgs frequently have 100-300 profiles — each one a management burden, each one duplicating 90% of the permissions of another profile. This is the problem Salesforce is solving with Permission Sets.

The Permission Set Architecture

Permission Sets are additive. A user with a minimal profile ("Minimum Access" — just login rights) can receive one or more Permission Sets that grant exactly the access they need. Adding or removing a Permission Set from one user does not affect other users. This granularity eliminates the profile proliferation problem.

Permission Set Groups (PSGs) aggregate multiple Permission Sets into a single assignable unit. A "Sales Representative" PSG might include: "Account Management," "Opportunity Management," and "CPQ Quoting" permission sets. Assign one PSG to onboard a new sales rep — no need to remember which individual permission sets are required.

Muting Permission Sets solve an edge case: sometimes a PSG grants too much access for a specific sub-group. Rather than building a separate PSG, you add a Muting PS that removes specific permissions from the group for a subset of users. This is additive architecture with surgical removal capability.

-- Permission set assignment in SOQL
SELECT Id, PermissionSet.Name, PermissionSet.IsCustom,
       AssigneeId, ExpirationDate
FROM PermissionSetAssignment
WHERE AssigneeId = '0055g000003FABCAA4'
ORDER BY PermissionSet.Name

-- Check if user has specific permission
SELECT Id, UserId,
       PermissionSet.PermissionsManageCases,
       PermissionSet.PermissionsViewSetup
FROM PermissionSetAssignment
WHERE UserId = '0055g000003FABCAA4'
AND PermissionSet.PermissionsManageCases = true

-- PSG assignment
INSERT INTO PermissionSetAssignment (AssigneeId, PermissionSetId)
VALUES ('0055g000003FABCAA4', '0PS5g000001PSGA1')  -- PSG Id

The Migration Challenge in Large Orgs

Migrating from a profile-heavy model to permission-set-first is conceptually simple but operationally difficult at enterprise scale:

• Audit what permissions each profile actually grants: Many enterprise profiles have hundreds of permissions enabled, many of which are unnecessary holdovers from years of incremental additions. A permission audit before migration often reveals 30-50% of profile permissions are not actively used.
• Map profiles to PSG equivalents: For each profile, define the equivalent PSG. This requires understanding which users are on the profile and which subset of permissions they genuinely need — not just what the profile has historically granted.
• Test permission changes: Permission changes have no "undo" — they take effect immediately on save. Test every PSG configuration in a sandbox with a representative set of users before production deployment.
• Handle profile-only features: Some settings are still profile-only in 2026 — Login IP ranges, session settings, password policies, and some system permissions are not yet available on Permission Sets. These settings must remain on profiles until Salesforce adds them to Permission Sets.

New Org Design: Permission-Set-First

For new implementations, the recommended architecture:

1. One minimal profile per licence type: "Minimum Access" (or a custom equivalent) for all users. This profile grants only login rights and the settings not yet available on Permission Sets.
2. One PSG per business role: "Sales Rep," "Service Agent," "Sales Manager," "System Admin." Each PSG bundles all the Permission Sets that role needs.
3. Atomic Permission Sets per feature: "CPQ Quoting Access," "Case Management," "Order Entry." These are the building blocks of PSGs. Build them at the smallest sensible granularity.
4. Muting PS for exceptions: When a subset of a role needs fewer permissions, add a Muting PS to the PSG for that subset rather than creating an entirely new PSG.