Salesforce's permissions U-turn was the wrong call

Salesforce didn't just delay the retirement of profile-based permissions. They cancelled it! Here's why their response doesn't match the complaint, and why the case for migrating to permission sets hasn't actually changed.

Salesforce recently cancelled its plan to retire system permissions from profiles. The move had been on the roadmap since 2023, was due to begin rollout in the Spring '26 release, and is now shelved with no new date attached. Salesforce cited customer feedback and feature gaps as their reasons.

The Salesforce community's reaction, based on the coverage I've seen, has been a mix of relief and "not totally surprised". Fair enough, Salesforce has a track record of moving controversial deadlines. But I want to make a different point: they didn't just delay this change. It was a full cancellation of the direction of travel, and other than "we're really into Agentforce right now", I can't see a good reason to go that far.

The complaint was real - the response wasn't proportionate

I understand where the pushback came from. Profiles are deeply embedded in orgs that have been running for years. Migrating to a permission set-centric model on a fixed deadline means months of analysis, testing, and change management, for a change that produces no visible business impact for the organisation. In a lot of enterprise contexts, that's a hard sell against anything revenue-generating.

That's a legitimate case for phasing the deadline, or extending it, or scoping it by org complexity. It is not a case for cancelling the initiative altogether. Salesforce had a whole menu of options that would have respected the complaint without also telling every customer "the pressure to fix this is gone“. Instead they picked the one option that removes the incentive to fix anything.

Some of those options could look like this:

Freeze forward, don't touch the past. From a set date, no new system or object permissions can be added to any profile, existing or new. Existing profiles keep what they have. Every incremental grant from that point on goes through a permission set. This stops the bloat problem at the source without breaking anything already in place.
New orgs go permission set-only. Existing orgs keep their profiles for now, but any org created after a given date cannot assign system permissions via profiles at all.
No new profiles, full stop. Existing orgs keep their existing profiles indefinitely, but from a set date they can no longer create new ones. Any new access requirement has to be built as a permission set.
Tiered runway by complexity. A small org with ten profiles doesn't need the same multi-year grace period as an enterprise org with two hundred profiles. Give the simple orgs a short deadline and the genuinely complex ones the longer runway. A blanket cancellation rewards whoever dragged their feet longest and does nothing for whoever already started the work in good faith.
A sunset clause, not an open-ended cancellation. Keep profiles alive, but attach a hard, published end-of-life date, five years out, ten years out, whatever's realistic. There's a real difference between "delayed, with a firm date attached" and "cancelled, no date, don't ask." Salesforce picked the version that removes all pressure.
Flag it without breaking it. Surface profile permission bloat as an escalated severity item in the Security Health Check menu, visible to admins and auditors, without a hard technical cutoff. It keeps the pressure social and reputational instead of a cliff edge, which might have been a reasonable middle ground if the real worry was breakage rather than effort.

Any of these would have kept the direction of travel intact while giving enterprise customers the breathing room they were asking for. Salesforce didn't need to choose between 'hard deadline' or 'no deadline at all'. They chose the second one anyway.

Profiles bloat because they're one-dimensional

Here's the part that actually bothers me, beyond the process question. I've reviewed a fair number of orgs over the years, and profile-based permission models tend to converge on the same failure mode: they get overly permissive, not because anyone made a bad decision, but because of how profiles are structured.

Take a fundraising team. Brian works Major Donor and Sarah works Corporate Fundraising. Both sit on the same "Fundraising User" profile because, at the time it was built, their access needs looked similar enough to share. Later, Sarah picks up some Community Fundraising responsibilities and needs access to a new set of fields and objects. Someone updates the shared profile to give her that access.

Brian now has it too. Not because he needs it. Because he happens to share a profile with someone who does.

Multiply that over a few years and a handful of role changes, and you get a profile that grants far more than any individual on it actually uses. Nobody made one wrong decision. The structure just doesn't support granularity, so every incremental change leaks sideways into everyone else on the same profile.

Permission sets handles it cleanly. Sarah gets a "Community Fundraising Access" permission set group assigned to her, and only her. Brian's access stays exactly where it was. Nobody's default footprint expands just because a colleague's job description did. That's what principle of least privilege looks like in practice: access that maps to the person and the task, not to whichever bucket they were sorted into years ago.

The forced migration deadline was, whether Salesforce framed it this way or not, a genuinely useful nudge to revisit the bloated profiles. It gave admins and consultants a mandate to say "we have to do this anyway, so let's do it properly". That mandate is gone now. The incentive hasn't been removed for the customers who were already disciplined about this. But it's been removed for everyone else, which is probably most orgs I imagine.

Where this leaves security posture

Salesforce has spent the last year talking about security and risk in increasingly serious terms. That's great! But you don't get to talk about a more purposeful security posture in one breath and, in the next, cancel one of the more meaningful structural nudges toward exactly that posture. The two positions don't sit well together.

We all know it isn’t a single security setting that will make or break your org. An org’s security posture is made up of layers upon layers of security settings and practices. The permissions which are granted through a user’s profile is a significant factor in those layers. The Salesforce data breaches in 2025 and 2026 have likely been exacerbated by overly permissive user settings.

Here's my take: treat the cancellation as Salesforce's problem, not yours. The best practice hasn't changed just because the enforcement mechanism disappeared. If you're an admin or a consultant sitting with a client's bloated profile model, the case for migrating to permission sets is exactly as strong today as it was the week before this announcement. You just no longer have Salesforce's deadline to point to when you make that case internally. You'll have to make it on the merits instead.

Which, frankly, you should have been able to do anyway.

Salesforce is betting that most orgs will take the path of least resistance now that nobody's forcing the issue. My hope is that we'll do better than Salesforce is apparently expecting of us.