Use a profile for a short list of baseline settings and permission sets (bundled into permission set groups) for everything else. That is still Salesforce's recommended model in 2026, even though Salesforce has cancelled its plan to retire permissions on profiles. Profiles are not going away, and you do not have to migrate by a deadline, but building new access on permission sets is still the safer, easier-to-audit choice.
This guide explains the difference in plain terms, what Salesforce has actually said about the retirement plan, and how to move from profile-heavy access to a permission set model without breaking your team's day.
Profiles vs permission sets in plain language
A profile is the base set of access every user has. Each user has exactly one. It holds object permissions, field permissions, system permissions, and some settings that only profiles control.
A permission set is a bundle of extra permissions you add to a user. A user can have many. A permission set group bundles several permission sets together for one type of person, such as "Case Manager" or "Development Coordinator".
| Profile | Permission set | Permission set group | |
|---|---|---|---|
| How many per user | Exactly one | Many | Many |
| Purpose | Baseline and a few special settings | Add specific access | Add a whole job's access in one assignment |
| Best for | Minimum starting point | Small, reusable pieces of access | Role-based access for a persona |
| Can be time-limited | No | Yes, with assignment expiration | Yes, with assignment expiration |
The problem with profiles alone is multiplication. If Case Managers in two programs need slightly different access, you clone the profile. Do that for years and you end up with dozens of near-duplicate profiles that nobody dares to touch. Permission sets let you give a small piece of extra access without cloning anything.
What Salesforce has said about retiring profile permissions
This is the part that causes the most confusion, so here is what we could verify (checked November 2026).
- In January 2023, Salesforce announced an end of life for permissions on profiles, with a target of the Spring '26 release. It was never the end of profiles themselves, only the ability to grant permissions on them. This is described in Salesforce's Admin blog.
- Salesforce later stopped enforcing the Spring '26 date, according to Salesforce Ben.
- Salesforce has a Help article titled Permissions in Profiles Retirement Cancelled. Secondary coverage reports it was published in mid-2026 and cites customer feedback and remaining feature gaps. We could not load the article text ourselves, so read it directly for the exact wording and date.
- Secondary coverage also says profiles will not receive new investment, and that Salesforce still recommends a permission set-led model.
What this means for you: there is no deadline forcing a migration. But the direction of travel has not changed, and the reasons for it (easier audits, less duplication, least privilege) still hold. If you are planning a Salesforce security review anyway, build toward permission sets.
What still has to live on a profile
Salesforce's own guidelines for permission sets and permission set groups split things this way (checked November 2026):
- Put in permission sets: object permissions, field permissions, user permissions, tab settings, Apex class access, Visualforce page access, custom permissions and connected app access.
- Keep on profiles: default apps and record types, IP ranges, login hours and page layout assignments.
Salesforce also recommends starting users on the Minimum Access - Salesforce profile (or a clone of it) and granting everything else through permission sets. Check the current documentation before you plan around this list, because Salesforce adds features over time.
A practical migration plan
You do not need to migrate everyone at once. Work in this order.
- Inventory what you have. In Setup, search Profiles in Quick Find and list every profile with its user count. Many orgs find profiles with zero or one user.
- Group your users by what they actually do. Think job types, not job titles: intake, case management, fundraising, finance, reporting, admin.
- Design permission sets around tasks. For example, "Create and edit Care Plans" or "Run and export donor reports". Keep each one small, with a name that says what it grants.
- Bundle them into permission set groups. One group per type of person. A user who does two jobs gets two groups.
- Test in a sandbox with real scenarios. Log in as a test user (a clearly fake one) and confirm they can do their job and cannot see what they should not.
- Move a pilot group first. Switch their profile to Minimum Access, assign the permission set group, and compare what they can do before and after.
- Roll out in waves, then deactivate or delete profiles that no longer have users.
Two cautions. First, permissions from a permission set only work if the user's license supports them, so check licenses when a permission seems to "not work". Second, the profile is still where record types, default apps and page layouts live, so a user on Minimum Access still needs those handled.
Two features worth using
Muting permission sets let you remove a permission from a permission set group without editing the underlying sets. That avoids cloning a set just to take one permission away.
Assignment expiration lets you give a permission set to a user until a date, for example a temporary coverage assignment. When the date passes, access ends without someone having to remember. This is documented in Salesforce's help on permission set assignment expiration.
Watch out for these mistakes
- Cloning "System Administrator" for power users. It carries View All Data and Modify All Data. See our guide to PHI and permissions for why that matters.
- Permission sets that grow forever. A set named "Case Manager Plus" with 200 permissions is just a profile with a new name.
- Skipping the review afterward. Migration is a good time to find people with more access than they need. Our guide to finding over-permissioned users shows how.
- Forgetting integrations. Integration users often sit on their own profiles. Check them before you change anything.
Frequently asked questions
Is Salesforce getting rid of profiles?
No. Profiles remain. The announced plan was to end the ability to grant permissions on profiles, and Salesforce has since cancelled enforcing that plan. Read the Salesforce Help article linked above for the exact current position.
Should I still migrate to permission sets?
Usually yes, over time. Salesforce still recommends a permission set-led model, and it makes access reviews far simpler. But there is no need to rush or to migrate profiles you do not touch.
Can a user have more than one permission set?
Yes. A user has one profile but can have many permission sets and permission set groups.
How long does a migration take?
It depends on how many profiles you have and how messy they are. A review of your current setup is the quickest way to find out.
Want a second pair of eyes on your access model?
If you are not sure how many profiles you really need, we can look at your org with you. Book a free Salesforce health check and leave with a clear list of what to clean up first. If you want a ready-made structure, our Security Framework Design offers governance templates for roles, profiles and sharing rules.