Profiles vs. Permission Sets in Salesforce: The Deadline Is Gone, the Decision Isn't

In January 2023, Salesforce told every admin still running access control through profiles to start moving permissions into permission sets, with a Spring '26 end-of-life as the forcing function. In 2026, Salesforce cancelled that deadline. A product director said the company would "no longer enforce" it, and the Knowledge article was quietly rewritten. If the only reason a permission-set migration was on your roadmap was the deadline, it just came off the roadmap too - and that's worth pausing on, because the deadline was never actually the risk. The risk is what accumulates on a profile, or inside a permission set, over three or four years of nobody being assigned to review either.

The short answer

In brief: nothing forces you off profiles anymore, but the direction Salesforce still recommends hasn't changed, and most 50-500 seat orgs have the same four gaps regardless of what the deadline says: profiles that kept growing after the "official" migration, permission sets reassembled into the same sprawl they were meant to fix, integration traffic running through a shared admin login instead of a dedicated user, and a Shield subscription bought for the name rather than a documented need. None of the four need an external deadline to matter - they cost you the moment an auditor, an incident, or an integration partner asks a question the access model can't answer cleanly. A Salesforce Health & Roadmap review checks all four as part of its security pass, which is usually faster than reconstructing the answer from scratch after something's already gone wrong.

Why the deadline got cancelled, and why that's not the same as 'fixed'

Salesforce's own reasoning for pulling back wasn't that the permission-set model was wrong - it was that too many orgs weren't ready, and change sets made the migration itself painful enough that forcing it risked breaking production access for customers who hadn't finished. That's a real, defensible reason to cancel a deadline. It is not a reason the underlying problem - permissions scattered across whichever layer happened to be convenient at the time - went away. Salesforce's sharing model has the same failure shape: nobody notices the debt accumulating until the day someone needs a precise answer to "who can see this, and why."

1. January 2023

   Retirement announced

   Salesforce said it would phase out permissions assignable directly on profiles, moving granular object and field access into permission sets and permission set groups.

2. Spring '26 (original target)

   Planned end-of-life

   The date admins were told to have completed the migration away from profile-level object and field permissions by.

3. 2026

   Retirement cancelled

   Salesforce confirmed it will no longer enforce the Spring '26 end-of-life date. Profiles continue to support permissions, with no forced deadline in place - but the permission-set-led model is still the recommended direction.

Four places a permission model actually breaks

Each of these shows up in a live org independently of the others - a profile can be bloated while the integration user is clean, or vice versa. Check all four; most orgs that come to us for a security cleanup have two or three active, not one.

1. Profiles kept growing after the 'migration' everyone thought was happening

A profile built during the original implementation, three or four Salesforce releases ago, almost never shrinks on its own - new objects get added, a consultant grants "just this one field" directly on the profile because it's faster than building a permission set for one person, and the profile quietly becomes the actual source of someone's access instead of a baseline. The fix isn't zero profiles; Salesforce itself still recommends keeping login hours, login IP ranges, default record types, and page layout assignment on the profile. It's collapsing the profile list down to a small number of restrictive, generic baselines - a "Minimum Access" profile per license type is the common pattern - and treating every object or field grant beyond that baseline as something that belongs in a permission set, not an exception bolted onto one more profile.

2. Permission sets can recreate exactly the sprawl they were supposed to fix

Moving grants off profiles doesn't help if the replacement is forty permission sets, each built for one person's specific situation and never looked at again - that's the same debt in a different table. The discipline that actually prevents it: one permission set per clearly named capability ("Case Management," "Export Reports"), bundled into permission set groups by role, with a single muting permission set per group reserved for the rare, documented exception that removes a permission the group would otherwise grant. We'd rather see one muting exception on a well-scoped group than a second group created every time one person needs one thing removed - a new group per exception is how you end up back at profile-era sprawl, just renamed.

3. Integration traffic is still running through a shared admin login

This is the cheapest fix on this list and the one we see skipped most. Since March 2023, Enterprise, Performance, and Unlimited edition orgs each get five free Integration User licenses - API-only, no UI access, and deliberately restricted to permission-set-based grants rather than profile permissions, so the access has to be scoped deliberately instead of inherited from whatever profile the user object happened to carry. Additional licenses cost roughly $10 each. A dedicated user per external system, named after that system, with its own narrowly-scoped permission set, means a compromised or misbehaving integration has a contained blast radius and an audit trail that says which system did what. A shared "integration@" login running as a full admin means neither is true, and rotating or revoking it means touching every connected system at once instead of one.

4. Shield gets bought for the name, not the documented need

Salesforce Shield bundles three genuinely different things, and "we should probably have Shield" usually means nobody has separated which of the three they actually need. Field Audit Trail extends standard field history - 20 fields per object, 18 months of retention - out to 60 fields and 10 years, which only matters if there's an actual multi-year audit or regulatory retention requirement behind it. Event Monitoring gives visibility into login, API, and (increasingly) agent-action behaviour, which matters once there's something specific you need to detect, not as general-purpose peace of mind. Platform Encryption matters when a named regulatory or contractual requirement demands encryption at rest on specific fields, not as a default upgrade. List pricing runs roughly 10% of net spend per component, and vendor negotiation write-ups report blended rates meaningfully below the headline bundle figure - which is itself a reason to ask your account executive whether you can license the one component you need rather than the full set, before assuming the bundle is the only option.

What we're advising clients right now

Don't let the cancelled deadline reset a cleanup that was already overdue for reasons that have nothing to do with Salesforce's timeline - an incoming SOC 2 or ISO audit, a new integration partner asking what your access model actually looks like, or simply not being able to answer "who can see this field and why" in under a day. If a profile or permission set audit hasn't happened since the original rollout, that's usually a half-day of decisions once someone's given the authority to make them, not a multi-month project - and it's exactly the kind of bounded, well-understood problem a Salesforce Fix Sprint is built for. If you're not sure which of the four items above is already drifting, talk to us before it shows up as an audit finding rather than after.

Questions worth asking before the next access review

Do we still need to migrate off profiles now the deadline is cancelled?

Not urgently, and not on anyone else's timeline. But the direction Salesforce recommends - minimal baseline profiles, permissions pushed into permission sets and permission set groups - hasn't changed, only the forcing function did. Treat the cancellation as removing a reason to panic, not as removing a reason to clean up a profile that's accumulated four years of ad hoc grants.

Can we buy just one Shield component instead of the full bundle?

Ask your account executive directly - sources disagree on how readily Salesforce sells Field Audit Trail, Event Monitoring, or Platform Encryption as standalone SKUs outside negotiated enterprise deals, and the answer has shifted over time. It's worth asking before assuming the ~30%-of-net-spend bundle figure is the only number on the table, particularly if only one of the three components maps to an actual requirement you have.

If we only fix one thing from this list, which one?

Dedicated integration users. It's the only item on this list that's free for the first five licenses, doesn't require touching your existing profile or permission set structure, and closes the single highest-blast-radius risk - a shared admin login with no attribution and no safe way to rotate it - without a project around it.

The bottom line

A permission model doesn't fail from one bad decision - it drifts from a hundred reasonable-sounding small ones, each made under time pressure by someone who moved on before the next person inherited the result. The Spring '26 deadline was never going to fix that by itself, and its cancellation doesn't make the drift disappear either. What actually keeps a 50-500 seat org's access model honest is the same four checks above, run on a schedule nobody else is going to impose for you.