Salesforce has cancelled the retirement of permissions in profiles, originally planned for Spring ’26, after customer feedback showed the ecosystem was not ready and a few feature gaps remained. Nothing about security best practice changed. Least privilege through permission sets and permission set groups is still the model to build. The difference is that you now migrate on your own schedule instead of against a countdown.
In This Article
Somewhere in your backlog sits a ticket called “migrate profiles to permission sets.” It has been there since 2023. It has survived three reprioritization meetings, two admin handovers, and at least one consultant who swore it was urgent. As of last month, the deadline behind that ticket no longer exists.
In June 2026, Salesforce updated its official Knowledge article to say the retirement of permissions in profiles has been cancelled. Not delayed. Not deprioritized. Cancelled. The enforcement that was planned to begin with Spring ’26 is off the calendar entirely, based on customer feedback and remaining feature gaps.
To understand why this matters, it helps to see how long this deadline lived.
Salesforce announces that permissions on profiles will retire, with Spring ’26 as the target. Three years feels like a generous runway, and the ecosystem starts planning.
Cheryl Feldman, Director of Product Management, announces that Salesforce will no longer enforce the Spring ’26 end-of-life date, while still recommending a permission set led security model.
Salesforce’s Knowledge article is updated: the retirement is cancelled based on customer feedback and remaining feature gaps. Profiles continue to support permissions.
Salesforce Ben and community voices pick up the story. The consensus lands in an interesting place: the deadline is gone, but the migration is still worth doing.
This is, as far as I can tell, the first time Salesforce has fully cancelled a retirement of this scale rather than pushing the date. Retirements have slipped before. Salesforce for Outlook moved from 2024 to 2027. But a complete cancellation of a change that would have touched every single org is new territory, and it says something about how seriously Salesforce weighs customer readiness.
The official reasoning comes down to two things: customers pushed back, and the tooling was not fully ready to support a clean migration at scale. Both are true, and both deserve a closer look.
Start with the adoption number. When roughly four out of five orgs have not completed the transition three and a half years after the announcement, forcing the change would have created real pain for real customers. That is not a hypothetical. That is production access breaking on a Tuesday.
Then there are the gaps. Record type defaults and app defaults never made a clean landing in permission sets. Page layout assignment still lives on the profile, and Salesforce has been clear that the future of layouts is Lightning App Builder and Dynamic Forms rather than porting the old assignment model over. Forcing a retirement while those pieces were unfinished would have pushed customers into workarounds nobody wanted.
Walking away from a deadline the tooling cannot support is the responsible move. Salesforce listened to feedback, looked at actual adoption data, and chose customer stability over an arbitrary date. Meanwhile, investment continues where it counts: the improved user management experience in Setup, permission sets, permission set groups, and summary views. The direction did not change. The forcing function did.
I will admit the cancellation stings a little for those of us who ran client migrations against this timeline. But every one of those migrations left the org in a better place. Cleaner access, and audits you can actually run. None of that work is wasted, and I would make the same recommendation again today.
Here is the part that gets lost in the headlines. Salesforce cancelled the retirement. It did not cancel the recommendation. The official guidance is the same as it was last year: adopt a least privilege model using profiles for baseline settings and permission sets for access control.
If you are designing this from scratch, or untangling an org that grew organically since 2014, this is the layered model that works:
Default assigned apps, page layout assignment, record type defaults, login hours, and IP ranges. One profile per user category, as few as you can manage. Many mature orgs get down to a single profile.
Object access, field access, system permissions, and Apex class access, grouped by function. “Manage Quotes” or “Export Reports”, not “Everything the Sales Team Might Need Someday.”
Bundles of permission sets that map to actual jobs. A Sales Manager group might contain six functional sets. Assign the group, not six individual sets.
Remove specific permissions from a group without rebuilding it. Useful when one region or one team needs almost everything the group grants, minus one sensitive item.
Profiles are rigid. Every user gets exactly one, and stacking exceptions into profile clones is how orgs end up with 74 profiles and no idea who can delete an Opportunity. Permission sets compose. That composability is why the recommendation stands regardless of any retirement date.
There is a second reason the permission set model matters more in 2026 than it did in 2023, and it has nothing to do with retirement dates. Your org is about to have more non-human users than human ones.
Every Agentforce agent runs as a user with an identity and a set of permissions. When an agent creates a case, updates an order, or queries customer data, your permission model is the thing standing between “helpful automation” and “an agent that can touch everything.” Agents do not squint at a warning and think twice. They act on whatever access they have, at machine speed.
Each agent should have its own user and its own permission set. Shared access between agents makes auditing agent actions nearly impossible.
A service agent that handles order inquiries needs read access to Orders and write access to Cases. It does not need Modify All Data. Ever.
When each agent’s access lives in a named permission set, “what can this agent do” is a thirty second question instead of a forensic project.
Try building that on profiles. You would need a new profile per agent, each one carrying the full weight of layouts, defaults, and settings the agent will never use. Permission sets were built for exactly this shape of problem: granular, composable, assigned to a specific identity for a specific purpose. The agent era is quietly the strongest argument for the permission set model Salesforce has been recommending all along.
The cancellation hands you a gift most platform changes never do: time. Use it to do the migration properly instead of rushing it against a date. Here is the sequence I run with clients.
Not sure where your org stands today? One query tells you a lot about how much access still flows through profiles versus standalone sets:
SOQL// Assignments per permission set (profiles excluded) SELECT PermissionSet.Name, COUNT(Id) assignments FROM PermissionSetAssignment WHERE PermissionSet.IsOwnedByProfile = false GROUP BY PermissionSet.Name ORDER BY COUNT(Id) DESC
If that list is short and your profile count is long, you know which direction the work runs.
A cancelled deadline is easy to misread. Before anyone closes that migration ticket as “won’t do,” a few clarifications are in order.
- No forced migration date hanging over your roadmap
- Profile based access keeps working, so nothing breaks
- You control the pace and sequencing of the transition
- Salesforce demonstrated it adjusts plans based on customer readiness
- Profiles are not getting new permission features or investment
- Least privilege did not stop being the recommendation
- Page layouts remain profile era; Dynamic Forms is the direction
- Building new access logic on profiles today is still the wrong call
There is also a quieter lesson here about how the community responded. The admins and architects who finished their migrations are not complaining. On Salesforce Ben, one commenter described completing the move and running a sizable org on a single profile, calling the switch something teams should prioritize rather than postpone. The people who did the work got the benefit. The deadline was never the point.
Looking ahead, the question for your org is simple. Salesforce has removed the external pressure and left the internal one: would your access model pass a security review today? If an auditor asked who can export customer data, could you answer in minutes? If a new Agentforce agent went live tomorrow, would its access be scoped or inherited from something built in 2019?
The retirement is cancelled. The reasons for it are alive and well. The orgs that treat this as breathing room, rather than a reprieve, are the ones that will be glad they did.