The answer, briefly: profiles are not being retired. Salesforce cancelled the end-of-life for permissions on profiles that had been planned for Spring ’26, and said so in a Help article published on 6 June 2026: “This enforcement has now been cancelled based on customer feedback and remaining feature gaps.” Profiles still exist, still work, and are still supported. The migration to permission sets is no longer forced, and is still the right direction, for reasons that have nothing to do with a deadline.
Most of what you’ll read about this is out of date
Worth stating plainly, because the volume of content asserting the opposite is large and much of it ranks well. Migration guides, conference talks, and blog posts written between the original announcement and June 2026 all describe a Spring ’26 cliff edge. That cliff does not exist. If your plan assumed a forced cutover, the deadline pressure in it is gone.
What has not changed is the recommendation. The same Help article that cancels the enforcement restates the target model in the next breath: “Although profile-based permissions are still supported, Salesforce recommends adopting a least-privilege model using profiles for baseline settings and permission sets for access control.”
So the correct reading is not “the migration was called off.” It’s “the migration lost its deadline and kept its rationale.”
Read the investment list, not the cancellation
The most useful sentence in the cancellation notice is not the cancellation. It’s the list of what Salesforce says it is continuing to invest in: an improved user management experience in Setup, permission sets and permission set groups, and summary views and admin usability improvements.
Profiles are not on that list. Salesforce’s position, as communicated to the admin community alongside the cancellation, is that no further improvements to profiles are planned and that effort goes to permission sets, permission set groups, and related features. That exact phrasing isn’t in the Help article, so take the wording as reported rather than quoted, but the article’s own investment list points the same way, and the metadata bears it out. New capabilities keep landing on PermissionSet and not on Profile: external credential principal access at API version 59.0, email routing address access at 62.0, both with no profile equivalent.
That is the durable argument for migrating. Not a deadline to beat, but the fact that what you are standing on has stopped moving while the alternative has not.
The practical position
1. Stop adding permissions to profiles today
This costs nothing and it is the only step with no downside. Every permission you add to a profile from now on is work you will redo. Make it a rule for your team rather than a project: new access requests get a permission set, always, even when editing the profile would be two fewer clicks.
The reason this works as a standalone move is that permissions are cumulative. Revoke Permissions and Access states it directly — “you can use profiles, permission sets, and permission set groups to grant access but not to deny access” — with the example that if Transfer Record is off in the profile but on in a permission set, the user can transfer records. A permission set never conflicts with the profile beneath it, so you can start layering immediately without untangling anything first.
2. Build permission set groups by persona, not by permission
Salesforce describes the intent: “Use a permission set group to bundle permission sets together based on user job personas or roles.” Compose each group from small single-purpose permission sets, then assign the group.
The argument for groups over assigning eight permission sets directly is auditability. “This user is in the Collections Specialist group” is an answer; “this user has these eleven permission sets” is a list. In a security review you want the first kind.
Get the granularity right, though. Permission sets mapping to a single capability (Export Reports, Manage Price Books, Convert Leads) compose well into many personas. Permission sets that each mirror a persona defeat the point: you maintain the same permission in six places, which is exactly the problem profiles had.
3. Reduce profiles to layouts and login settings
The end state is minimal profiles. Salesforce’s guidance: “when possible, assign users the Minimum Access – Salesforce profile, or a clone of it if you’re modifying the included default settings for different users.” That standard profile “grants the least privileges in the Salesforce platform,” carrying only Access Activities, Chatter Internal User, Lightning Console User, and View Help Link.
You will need clones of it, because page layout assignment cannot be done from a permission set. That constraint (not permissions) should determine how many profiles you keep.
4. Use the tooling, and know what it skips
The User Access and Permissions Assistant app converts a profile with a Salesforce license into an editable, assignable permission set. What it does not carry across is the profile-only material: default apps, default tabs, default record types, page layout assignments, and login IP ranges and login settings. Which is the correct behaviour, since none of those can live in a permission set, but it means the conversion output is never the whole job.
For assignment at scale, User Access Policies is GA on Enterprise and Unlimited. A policy can assign permission set licenses, permission sets, permission set groups, package licenses, queues, and public groups in one operation, either as a one-time manual run or as an active policy triggered on user create and update. Where several active policies match a user, “the policy with the lowest Order value is applied”, so set Order deliberately rather than letting it default.
Muting permission sets: the only subtractive tool you get
Because permissions are additive, a group containing a broad permission set grants everything in it. Muting is the exception, and it is narrower than people expect.
A muting permission set is created from inside a group (Muting Permission Set in Group → New), and only one is allowed per group. It cannot be assigned to a user directly. Its scope is exactly the group it belongs to: “when you mute a permission in a permission set group, the muting affects only users assigned to the permission set group, not users assigned directly to a permission set outside of the permission set group.”
That last clause is the part that catches people. Muting does not remove a permission from a user. It removes it from one path to that user. If the same permission arrives via their profile, or via a permission set assigned directly, or via a different group, they still have it.
What you can mute is broad (“object, field, and user permissions and other access settings”), and structurally the muting metadata mirrors the permission set metadata, so app visibility, record type visibility, and tab settings are in scope too. Two behaviours to know before relying on it:
The dependency cascade works downward. Muting Read also mutes Create, Edit, Delete, View All Records, and Modify All Records. Muting Edit also mutes Delete and Modify All Records. Muting Delete also mutes Modify All Records. This is usually what you want, and it does mean a narrow-looking mute can remove more than the checkbox suggests.
Muting View All Data does not mute the object permissions inside it. The documentation is explicit: “if you mute the Modify All Data or View All Data user permissions, included object permissions aren’t affected.” You have to mute those object permissions explicitly as well. A mute that looks like it locked down an over-broad permission set may have done nothing of the kind — verify against a test user rather than reading the configuration.
My position: muting is a good tool for constraining a permission set you do not control (a managed package’s, typically), and a bad tool for expressing your own intent. If you own both sides, split the permission set instead. A group whose behaviour depends on a mute is harder to reason about than two smaller permission sets.
The numbers you are designing against
| Limit | Enterprise / Unlimited |
|---|---|
| Permission sets created | 1,000 |
| Permission sets created plus installed managed package | 1,500 |
| Permission set groups created | 800 |
| Permission set groups created plus installed managed package | 1,000 |
| Permission sets in one group | 100 |
| Muting permission sets per group | 1 |
Professional Edition is capped at 10 permission sets, Essentials at 5, and per the Help article on raising the limit, this “cannot be increased by Salesforce Technical Support” and moves only with an edition upgrade or an add-on. If you are on Professional, single-purpose permission sets are a luxury you do not have, and the persona-shaped compromise is forced rather than lazy.
There is no documented maximum number of permission sets assignable to one user. I looked, including in the edition allocation pages, and found only that users “can have multiple permission sets” depending on edition. If you see a specific per-user figure quoted anywhere, treat it with suspicion.
Two behaviours that will surprise you
Group recalculation is asynchronous and can be slow. “Because recalculation runs asynchronously, the processing time can range from seconds to hours for large or complicated updates.” A group sits in Updated, Outdated, Updating, or Failed status. While it is Outdated, changes are captured but users do not yet have the new permissions, and new user assignment to the group is blocked — though editing is still allowed. Users keep the permissions from the last completed calculation, so nobody loses access mid-recalculation. There is a manual Recalculate button on the group detail page when you need to force it.
A related trap: changes to your own permission sets inside a group are calculated immediately, but “permission changes for Salesforce-owned standard permission sets that are added to permission set groups are calculated daily.” Add a standard permission set to a group and the effect may not appear until tomorrow. That has burned a lot of go-live mornings.
Session-based permission sets stop requiring activation inside a group. A session-based permission set included in a permission set group grants its permissions to users assigned via the group without session activation. So dropping one into a group quietly converts temporary, time-scoped access into standing access. If you use session-based permission sets as a privilege-escalation control, keep them out of groups.
Frequently asked
Are profiles being retired?
No. The end of life for permissions on profiles that had been planned for Spring ’26 was cancelled in June 2026, “based on customer feedback and remaining feature gaps.” Profiles remain supported, and every user still has exactly one.
If the deadline is gone, should I still migrate?
Yes, but on your own schedule. The reason is no longer compliance, it is that profiles have stopped receiving investment while permission sets keep gaining capabilities. Start with the free part (stop adding permissions to profiles), and migrate existing ones as you touch them rather than as a big-bang project.
Can a permission set remove access a profile granted?
No. Permissions are cumulative and can only grant. The single exception is a muting permission set inside a permission set group, and it only affects users who get the permission through that group.
Can I delete my custom profiles once everything is in permission sets?
Only down to the number your page layout assignments require, since layouts cannot be assigned from a permission set. Also check default record types, default app, login hours, and login IP ranges before deleting a profile — those are profile-only too, and the conversion tooling does not carry them over.
Why haven’t my permission set group changes taken effect?
Check the group’s status. If it reads Outdated or Updating, recalculation has not finished, and on a large group that can take hours. If you added a Salesforce-owned standard permission set, expect up to a day, because those are calculated daily rather than immediately.
How many permission sets can one user have?
There is no documented per-user limit. The org-level limits are what you plan against: 1,000 permission sets and 800 permission set groups on Enterprise and Unlimited, with a maximum of 100 permission sets in any one group.
Reference: Permissions in Profiles Retirement Cancelled, Migrate from Profiles to Permission Sets, Permission Set Groups, Muting Permission Sets, Muting Permission Set Dependencies, Permission Set Group Status and Recalculation, Permission Set Group Considerations, Revoke Permissions and Access, User Access Policies, Converting Profiles to Permission Sets, Standard Profiles, and Salesforce Enterprise Edition Allocations.
