Salesforce Profiles vs Permission Sets: 2026 Migration Guide

Salesforce profiles vs permission sets comes down to one rule: each user has one profile for baseline settings, and any number of permission sets add access on top. To migrate, assign the Minimum Access - Salesforce profile and move everything else into permission set groups, one wave at a time.

Clientell AI, the AI Salesforce admin, can map who holds which access today before you change anything. A profile is the one required record that holds a user's default app, login hours and page layouts. A permission set is a reusable bundle of extra permissions.

What do profiles still control that permission sets cannot?

Start here, because migration plans fail when someone assumes a setting is portable and then finds out on Monday that nobody has a page layout. Salesforce's own admin guide lists what a profile should carry: login IP ranges, login hours, default apps and record types, and page layout assignments.

Record type access (which types a user may use) can be granted by a permission set. Which type is the default stays on the profile. That is why you cannot delete profiles entirely. Every user needs one, and it is tied to a user license.

How do profiles and permission sets combine?

Permissions are a union, not a hierarchy. At login, Salesforce adds up the profile, each assigned permission set and each set inside each assigned group. The user gets the most permissive result.

If a forgotten 2022 project set grants Modify All Data, the user has it, however tight the profile is. A muting permission set is the only way to subtract, and it works only inside its parent permission set group. If the profile or a standalone set grants the same permission, the mute does nothing and no warning appears. Salesforce describes the mechanics in its help pages on permission set groups and muting permission sets.

Record access is a separate system. Which records a user sees depends on organization-wide defaults (OWD), roles and sharing rules. This migration leaves them alone.

Is Salesforce still retiring permissions on profiles?

No. Salesforce had planned to retire permissions on profiles starting in Spring '26. Its Help article Permissions in Profiles Retirement Cancelled, dated June 6, 2026, says that plan is cancelled.

Salesforce still recommends a permission set-led model. Its admin guide says to assign the Minimum Access - Salesforce profile, or a clone of it, when you can. No deadline forces this work. The reasons are practical: you stop cloning profiles, access reviews get shorter, and a role change becomes one assignment.

How do you migrate from profiles to permission sets?

Run these six stages in order. Each one has a result you can check and an undo.

1. Baseline and freeze. Stop creating profiles under Setup > Users > Profiles. Export every Profile, PermissionSet, PermissionSetGroup and PermissionSetAssignment record. Expected result: a CSV of who holds what. Failure case: an inventory that misses inactive users or hidden profile-owned sets. Undo: nothing changes yet.
2. Define the minimum viable profile. In Setup > Users > Profiles, group users by the five profile-only settings. Clone Minimum Access - Salesforce for each cluster that needs other defaults. Expected result: a short profile list. Failure case: cutting admin access inside this stage. Keep that as a separate tracked change.
3. Build permission set groups per job function. In Setup > Users > Permission Sets, create narrow sets such as PS_Opportunity_Delete, then compose them into groups such as PSG_SalesManager_AMER. Expected result: one group per job. Failure case: one set per old profile, which just renames the sprawl.
4. Diff in a sandbox. Use Setup > Users > Users > Permission Set Assignments to compare each sample user's effective permissions under the old and new model. Expected result: a list of losses and gains. Failure case: a field hidden by FLS on the new baseline, which shows a blank field instead of an error. Undo: delete the sandbox build.
5. Pilot one cohort. Pick a small, similar group and run a full business cycle, including month end. Expected result: each person's daily task list works, including Opportunity edits and report exports. Failure case: a user who cannot see Opportunity.Amount. Undo: restore User.ProfileId from your CSV with Data Loader.
6. Roll out in waves, then decommission. Insert PermissionSetAssignment rows for the new groups first, verify for a day, then switch User.ProfileId. Delete legacy profiles last. Salesforce blocks deleting a profile that still has users, but it lets you orphan a page layout assignment.

Step 1 queries

Run these in Workbench or the Developer Console. They read the User, PermissionSetAssignment and ObjectPermissions objects. The PermissionSetAssignment reference lists the fields.

SELECT Profile.Name, COUNT(Id)
FROM User
WHERE IsActive = true
GROUP BY Profile.Name
ORDER BY COUNT(Id) DESC

SELECT Assignee.Name, PermissionSet.Name, PermissionSetGroupId
FROM PermissionSetAssignment
WHERE Assignee.IsActive = true
AND PermissionSet.IsOwnedByProfile = false

SELECT Parent.Profile.Name, SobjectType
FROM ObjectPermissions
WHERE Parent.IsOwnedByProfile = true
AND PermissionsModifyAllRecords = true

The first query counts active users per profile. The second lists real assignments and skips the hidden set each profile carries. The third finds Modify All grants that live on profiles. The Permission Set Spaghetti cheat sheet has the rest of the query bank.

Then take your rollback snapshot. Retrieve the Profile, PermissionSet and PermissionSetGroup metadata into version control, tagged with the date. You cannot rebuild it from memory under pressure.

How do you design the groups and the Minimum Access profile?

Design from job functions, not from the old profiles. In Setup, open Users > Permission Set Groups, create the group, add sets, and then use the muting tab only where a group must be a strict subset of its sets. The Permission Set Groups Trailhead module walks through the clicks.

A structure that holds up:

Minimum Access - Salesforce grants almost nothing beyond logging in. Clone it when a population needs a different default app or record type. Standard profiles cannot be cloned or renamed in the usual way, so check the clone in Setup > Users > Profiles before you assign it.

Keep reduction and migration apart. Migrate to equivalent access first. Then cut Modify All Data and System Administrator spread as a separate change with named approvals. If you mix them, every breakage has two possible causes.

How can you automate assignment with User Access Policies?

User Access Policies grant or remove access when a user matches criteria, such as Department or Title on the User record. Salesforce documents them in its help page on User Access Policies. They fit the end state: once groups map to jobs, a policy can grant PSG_SalesManager_AMER when a user matches the criteria.

Test a policy on a few sandbox users first. An overly broad criterion assigns a group to people who should not hold it, so check the preview of matched users before you save.

What does the rollback plan look like?

Write it before wave one.

• Store each affected user's current ProfileId and permission set assignments as a CSV outside Salesforce.
• Name one rollback owner per wave, plus a backup.
• Set a trigger, for example any P1 access failure.
• Rehearse the reversal in the sandbox.

When you pull the trigger, restore the profile assignment first, using Data Loader on the User object. Leave the new groups assigned, because they are additive. Then have two real users from the cohort do their jobs before you call it recovered. Revert only the job function that broke, not the whole org.

What mistakes break these migrations?

• One permission set per legacy profile. You finish the migration and keep the sprawl of Sales User Copy FINAL.
• Muting to fix grants from elsewhere. The mute does nothing when a profile or standalone set also grants the permission.
• Skipping the FLS diff. Users report blank Opportunity.Amount fields as data problems.
• Forgetting integration users. A nightly sync fails at 2am when the API user lands in a wave.
• No naming convention. PS_New_Sales_2 and PS_Sales_Updated both exist and nobody knows which is live.

How does Clientell AI help, and is it safe?

Clientell AI scans your org in read-only mode first. It tests changes in a sandbox and asks before it changes anything in production. You can roll back each step, and the security page has details. Start with the free read-only permissions audit, or try the 14-day trial with no card.

Try it in Clientell AI: "List every active user with Modify All Data and show which profile or permission set grants it." Start the 14-day trial, no card.

If your admin has no time for this project, our managed services can run it, with Book a demo as the second option. Clientell AI makes one of the tools described here.

Sources

Salesforce documentation

• Permissions in Profiles Retirement Cancelled (Salesforce Help)
• Permission set groups (Salesforce Help)
• Muting permission sets (Salesforce Help)
• User Access Policies (Salesforce Help)
• PermissionSetAssignment object reference

Industry research

• The Salesforce Admin's Guide to Profiles and Permissions (Salesforce Admins)
• Permission Set Groups (Trailhead)

Last reviewed October 2026

Last updated: October 22, 2026