TL;DR
- Salesforce has cancelled the retirement of permissions in profiles. The enforcement was originally announced to begin in Spring '26. It is not happening, and no replacement date has been set.
- The stated reasons are customer feedback and remaining feature gaps. That second phrase is the interesting one: it is Salesforce confirming the tooling was not ready to replace everything profiles do.
- The recommendation is unchanged. Salesforce still says move to a permission set led model, and that advice survives the cancellation intact.
- If your migration was justified only by the deadline, it was justified badly. The real arguments are deployability, additive grants and auditability, and none of them depended on an end-of-life date.
- A few things still live only on profiles: login hours, login IP ranges, default record type, default app, and page layout assignment. Any plan that assumed profiles would disappear entirely was always wrong.
- The practical risk now is different from the one you were managing. It is not a missed deadline. It is a half-finished migration left in place indefinitely, which is worse than either end state.
What You'll Learn
- Exactly what was cancelled, in Salesforce's own words, and what was not
- What "remaining feature gaps" tells you about the state of the tooling
- The three arguments for permission sets that never depended on a deadline
- Which settings genuinely still require a profile
- How to decide what to do with a migration that is currently half done
The Problem
For two years, "profiles are going away" has been doing a lot of work in Salesforce access design. It ended arguments. It justified migration budget. It got permission set projects funded in orgs that had put them off for a decade, because a deadline is easier to sell to a steering committee than a principle.
That deadline is now gone, and a predictable thing is about to happen. Migrations that were sold on urgency will lose their funding, stall wherever they happen to be, and leave orgs in the worst configuration available: permissions spread across both profiles and permission sets, with no single place to answer "what can this person do".
The cancellation is good news badly timed. It removes a forcing function that a lot of teams were relying on instead of an argument.
Common questions this article answers:
- What exactly did Salesforce cancel, and is there a new date?
- If there is no deadline, is there still a reason to migrate?
- Which settings still require a profile no matter what?
Quick Answer
Salesforce has cancelled the retirement of permissions in profiles. The Salesforce Help article on it is titled "Permissions in Profiles Retirement Cancelled" and states that the enforcement, originally announced to start in Spring '26, "has now been cancelled based on customer feedback and remaining feature gaps", that profiles "will continue to support permissions for now", and that Salesforce still recommends transitioning to a permission set led security model. No replacement end-of-life date has been announced. Migrate anyway, for reasons that never depended on the deadline: permission sets deploy cleanly between environments where profiles do not, they are additive so you can grant capability without editing a shared baseline, and they make access auditable because a grant has a name and an assignment record. Do not attempt to empty profiles completely, because login hours, login IP ranges, default record type, default app and page layout assignment still live there. The real risk now is a half-migrated org left that way indefinitely, which is harder to reason about than either the old model or the new one.
What was actually cancelled
Precision matters here, because the announcement has been summarised loosely in a lot of places.
What was cancelled is the retirement of permissions in profiles: the plan to strip permission grants out of profiles and require them to live in permission sets. Salesforce's article says the enforcement "has now been cancelled based on customer feedback and remaining feature gaps", and that profiles "will continue to support permissions for now".
What was not cancelled is the direction. The same article recommends transitioning to a permission set led security model, and lists continued investment in permission sets and permission set groups, user management in Setup, and admin usability improvements.
Two things worth noting about what is absent. There is no replacement date, so anyone telling you the deadline has moved to a specific release is adding information the source does not contain. And the Help article itself carries no cancellation date, so treat specific dates circulating in secondary coverage with the scepticism they deserve.
"For now" is doing visible work in that sentence. This is a reprieve rather than a reversal of intent.
What "remaining feature gaps" tells you
The phrase is easy to skim past and it is the most useful part of the announcement.
Salesforce did not say it cancelled because customers disliked the work. It said customer feedback and remaining feature gaps. That is an organisation confirming that the replacement was not yet capable of everything the thing it replaced could do, which is a different and more credible admission.
It also validates something admins were saying and were occasionally told they were resisting change over. If your migration stalled because you hit a case permission sets could not express, you were not doing it wrong. You had found one of the gaps.
The practical consequence is that you should stop treating unresolved edge cases as your failure. Document them, leave them on profiles, and move the rest. A migration that gets 90% of grants into permission sets and honestly records the 10% that cannot go yet is a success, not an incomplete project.
The three arguments that never needed a deadline
If the deadline was your only reason, here is what you were actually buying.
Permission sets deploy. Profiles fight you. A profile in a change set or a metadata deployment carries a sprawl of settings, picks up whatever exists in the target org, and produces diffs nobody can review. Permission sets are self-contained, so a grant can move from sandbox to production as a reviewable unit. This is the argument that matters most to anyone running a real release process, and we make the case in full in Deployable permission sets for delivery teams.
Permission sets are additive, so you stop editing a shared baseline. Granting one person one extra capability by editing their profile changes it for everyone who shares it. That is how profiles accumulate: each grant is cheap, permanent, and invisible to the next person. An additive model lets you say yes to a request without widening a baseline, which is the mechanism by which least privilege survives contact with a busy quarter.
Permission sets are auditable because a grant has a name. "Why can this user export reports?" is answerable when the answer is an assignment record pointing at a named permission set. When the answer is "their profile has it, and so do the other 240 people on it", you cannot review access, you can only observe it. That is the difference between an access model you can attest to and one you inherit. It is also why the same argument runs through what developers actually need instead of Modify All Data.
None of these got weaker on the day the deadline was cancelled. They were never deadline arguments. They are operability arguments that happened to be riding on a deadline, and now have to stand on their own, which they can.
What still lives only on a profile
Any plan that assumed profiles would vanish was wrong even before the cancellation. A handful of settings have no permission set equivalent:
| Setting | Still profile-only |
|---|---|
| Login hours | Yes |
| Login IP ranges | Yes |
| Default record type | Yes, though record type access can be granted by permission set |
| Default app | Yes |
| Page layout assignment | Yes |
| Global publisher layout assignment | Yes |
The pattern is that profiles are being narrowed to defaults and restrictions, while permission sets carry grants. That is a coherent split, and it is a better mental model than "profiles are legacy". A user still needs a profile. It just should not be where you express what they are allowed to do.
Read that table as a design constraint rather than a disappointment. It tells you the target state: every profile in the org becomes a thin baseline that sets defaults and login restrictions, and every capability arrives through a permission set or permission set group.
If your migration is half done
This is the situation most orgs are now in, and it is the one worth thinking about properly, because "pause and reassess" is the most likely outcome and the worst one.
A half-migrated org has permissions in two places. Answering "what can this person do" now requires checking both, and the two can contradict each other in ways that are not obvious. You have taken on the complexity of the new model without retiring the old one, and you are paying for both.
Three honest options:
Finish it. If you are most of the way there, the remaining work is usually smaller than the cost of leaving it split. Set the target as "profiles hold defaults and restrictions only", accept the profile-only settings above as permanent residents, and close it out.
Stop cleanly at a defensible line. If the remaining cases are the hard ones, draw an explicit boundary. For example: all new grants go in permission sets, existing profile grants stay until touched. Write it down, because an undocumented boundary is indistinguishable from an abandoned project six months later.
Do not simply stop. The one choice with no upside is downing tools where the deadline found you. That leaves a split model nobody designed, which will be inherited by someone who was not in the room.
Whichever you pick, the deliverable is a written statement of where permissions live in your org. That document is worth more than the migration itself, because it is what makes the next access review possible. If you are sizing that work, access model sizing for internal and external admin teams covers how the effort scales.
Frequently Asked Questions
Q: Is there a new retirement date?
A: No. Salesforce's article states the enforcement is cancelled and that profiles will continue to support permissions "for now". It does not announce a replacement date. If you see a specific new release named as the deadline, check it against the Salesforce Help article before planning around it, because that detail is not in the source.
Q: Does this mean permission sets were a mistake?
A: No, and Salesforce's own article still recommends the permission set led model in the same breath as cancelling the deadline. What changed is the forcing function, not the direction. The cancellation is better read as an admission that the migration path had gaps than as a change of architectural mind.
Q: We paused our migration when we heard. What is the actual risk?
A: That you stay paused. A half-migrated org carries permissions in two systems at once, so every access question needs both answered, and the split was designed by nobody. That is worse to operate than either the old model or the new one. Either finish, or draw an explicit line and document it.
Q: Can we get rid of profiles entirely?
A: No. Login hours, login IP ranges, default record type, default app, page layout assignment and global publisher layout assignment have no permission set equivalent. Every user still needs a profile. The realistic target is a thin profile carrying defaults and restrictions, with all capability granted through permission sets.
Q: What should we tell a steering committee that funded this on the deadline?
A: That the compliance driver has gone and the operational one has not. The measurable arguments are that access becomes reviewable, grants become deployable between environments, and individual requests stop requiring edits to shared baselines. If your org has an audit or certification obligation, the auditability argument is usually the one that carries, because "the profile has it" is not an answer anyone can attest to.
Key Takeaways
- The retirement is cancelled, with no replacement date. Profiles keep their permissions, and the Help article says "for now".
- "Remaining feature gaps" is Salesforce confirming the tooling was not ready. If your migration hit a wall, you found a real one.
- The recommendation did not change. Permission set led is still the advice, in the same article that cancels the deadline.
- The three real arguments are deployability, additive grants and auditability, and none of them ever depended on an end-of-life date.
- Some settings are permanently profile-only, so the target is a thin profile of defaults and restrictions, not no profile at all.
- The dangerous outcome is stopping halfway, which leaves permissions in two places and an access model nobody designed.
What's Next?
Recommended Reading:
- Deployable permission sets for delivery teams
- What developers actually need instead of Modify All Data
- Access model sizing for internal and external admin teams
- Salesforce delivery team access model: tiers and roles
Action Items:
- Establish where your migration actually stopped, and whether permissions currently live in one place or two.
- Write down the boundary you are choosing: finish, or an explicit rule such as "all new grants in permission sets". An undocumented pause becomes an abandoned project.
- Record the profile-only settings your org depends on, so the target state is a thin profile rather than an impossible empty one.
Responses
Checking your session.
Loading responses.