After three years of roadmap slides, delayed deadlines, and migration planning sessions, Salesforce has quietly updated its Knowledge article to say that the retirement of permissions on profiles — originally scheduled for Spring ’26 — is cancelled. Not delayed. Not deprioritized. Cancelled.

If your first reaction was relief, I get it. But if your second reaction was “great, we can stop the permission set migration” — that’s the reaction I want to talk you out of.

What actually happened

A quick timeline, because this story has been running for a while:

  • January 2023 — Salesforce announces that permissions on profiles will be retired, with Spring ’26 as the target release.
  • 2024 — Cheryl Feldman, Director of Product Management for User Access, announces the first delay after strong community feedback.
  • June 2026 — the official Knowledge article is updated: the retirement is cancelled based on customer feedback and remaining feature gaps.

The stated reasons are honest, and both matter. Customers pushed back hard — an SF Ben admin survey found that only around 20% of organizations had fully transitioned to a permission set-led security model. And the tooling genuinely wasn’t ready: record type access, app defaults, and page layout assignment still don’t have complete permission set equivalents. Dynamic Forms and dynamic actions have come a long way, but they haven’t fully replaced what page layouts assigned via profiles do today.

In other words: Salesforce set a deadline for an architecture change before closing the feature gaps that made the change possible at scale. The cancellation is the right call. It’s also a useful lesson in what happens when a migration is driven by a date instead of a design.

The deadline was never the point

Here’s the thing I keep repeating in architecture reviews: the profile retirement deadline was the worst reason to move to permission sets. It was also, for many orgs, the only reason anyone funded the work.

The actual reasons to run a permission set-led security model haven’t changed:

  1. Composability. Profiles force you into a matrix: one profile per combination of job function and access level. Permission sets let you model access as building blocks — one set per capability, grouped into permission set groups per persona. When a new role appears, you assemble it instead of cloning and diverging.
  2. Least privilege. With a minimal baseline profile and access layered through permission sets, you can reason about what a user can do by looking at what they’ve been given, not by diffing two 40-page profile definitions.
  3. Auditability. “Why does this user have Modify All Data?” is answerable in a permission set-led model. In a profile-led org with years of clone-and-tweak history, it’s an archaeology project.
  4. Automation. User Access Policies can assign and remove permission sets automatically based on user attributes. There is no equivalent mechanism that manages profile sprawl for you.

The permission set-led model: a minimal baseline profile provides defaults, permission set groups provide access, and User Access Policies automate assignments

None of this stopped being true because a retirement got cancelled. Salesforce itself says the same thing in the cancellation notice: the recommendation is still a permission set-led security model, with profiles reduced to what they’re genuinely good at — defaults like assigned apps, record types, page layouts, login hours and IP ranges, and session settings.

What to do if you’re mid-migration

This is the situation I’d expect most enterprise orgs to be in: migration started, partially done, and now the forcing function is gone. A few concrete recommendations:

Don’t stop. Re-scope. The deadline justified a “migrate everything by Spring ’26” plan. Without it, you can sequence the work by value instead of by date. Object and field permissions, user permissions, and app access move to permission sets first — that’s where the audit and least-privilege wins are. Record types, app defaults, and layout assignment stay on profiles for now, because that’s exactly where the feature gaps are anyway.

Freeze profile proliferation. Even if you slow down the migration, put a hard rule in place: no new profiles. New personas get a baseline profile plus permission set groups. This costs almost nothing and stops the problem from growing while you work through the backlog.

Keep the target architecture in your governance docs. The risk of a cancelled deadline isn’t that the migration pauses — it’s that the decision evaporates. Six months from now, someone will propose a new profile “just for this one integration user,” and if the permission set-led target model isn’t written down as an architectural decision, you’ll be back to profile sprawl by next year.

Treat the feature gaps as the real roadmap. The gaps Salesforce named — record type access, app defaults, page layouts — are now the honest boundary of the migration. Track them. When Salesforce closes one, that’s your trigger to move that slice of access out of profiles, on your schedule.

The systems view

I’ve written before about thinking in systems, and this cancellation is a good case study. A deadline is a balancing loop imposed from outside: it creates urgency, but the moment it disappears, so does the behavior it drove. An architectural decision that only exists because of an external deadline was never really a decision — it was compliance.

The orgs that come out of this well are the ones that were migrating because composable, least-privilege access management is a better system — and for them, the cancellation changes the pace, not the direction. The orgs that were migrating because Spring ’26 was on a slide will stop, and in three years the gap between those two groups will be very visible in every security review.

Salesforce cancelled a deadline. It didn’t cancel the architecture. Keep going — just on your own terms now.