Profiles vs permission sets in 2026: Salesforce cancelled the deadline, not the cleanup

On June 6, 2026, Salesforce edited a support article and cancelled a deadline the ecosystem had planned around for three years.

The article, knowledge number 003834041, was retitled “Permissions in Profiles Retirement Cancelled.” The reason given was customer feedback and remaining feature gaps. There was no release note, no email, no keynote. Salesforce Ben found the edit and broke the story about five weeks later.

For anyone who built a Spring ‘26 migration into a roadmap, this matters, so let me give you the call up front. The deadline is gone and nothing in your org breaks. The reason to move most of your permissions off profiles is not gone, because it never rested on the deadline. Keep migrating what scales. Stop treating it as a fire drill.

What was going to happen, and what didn’t

Salesforce announced the end of permissions on profiles in January 2023, targeting the Spring ‘26 release. Object access, field-level security, and user permissions would leave profiles entirely and live only on permission sets. Profiles would survive as a shell for the settings that had nowhere else to go.

The plan softened in 2024, when Salesforce said it would no longer enforce the Spring ‘26 date. Most teams read that as a delay and kept a line item open, waiting for the new date. The June 2026 edit is the cancellation, not another delay. The word in the article title is “cancelled.”

The reason is the interesting part. Salesforce cited feature gaps, which is an admission that the tooling to do this cleanly at scale was not ready. The adoption numbers say the same thing. Salesforce Ben’s admin survey found only about a fifth of orgs had fully moved to a permission-set-led model, with most still leaning on profiles for real access. A retirement that half the customer base is not ready for is a support incident waiting to happen, and Salesforce blinked.

What the cancellation does not change

Two things survive the U-turn intact.

The first is Salesforce’s own direction. Every new investment in user management goes into permission sets, permission set groups, and the automation around them. Profiles are frozen in the same way a product at end-of-sale is frozen: supported, working, and done. Building new access on profiles today is building on a foundation nobody is pouring anymore.

The second is the security case, which was always the real reason. A profile is one-per-user and tends to accumulate permissions nobody remembers granting. When you need to answer “who can export all data, and why,” a permission set gives you a named, assignable, reportable grant you can query and revoke. A profile gives you a shrug. Least privilege is easier to prove when access is composed from small pieces than when it is baked into a monolith.

So the reprieve does not mean stop. It means do this right instead of doing it fast.

What still has to live on a profile

Before you move anything, know what cannot move, because a migration that strips a profile bare will break logins. Some settings have no permission-set equivalent and remain profile-only in 2026:

Login hours, the window a user is allowed to sign in
Login IP range restrictions enforced at the profile level
The default record type for each object
The default app and landing experience
Page layout assignment by profile and record type
Session settings that override the org defaults, and password policies

Record-type access and app access can and should move to permission sets. Which record type is the default stays on the profile. That distinction trips people up, so hold it: permission sets grant the ability, profiles still pick the default.

Everything else belongs in permission sets: object CRUD and field-level security, user and system permissions, Apex class and Visualforce access, custom permissions, and tab visibility. That is the bulk of what an access review ever asks about, and it is exactly the part that reports and audits cleanly once it is out of the profile.

The four pieces, and the trap in the middle

The model has four building blocks, and using them well is the difference between a clean estate and a worse mess than you started with.

A profile is the thin baseline: one per user, holding only the profile-only settings above. A permission set is a scoped grant you assign and revoke on its own. A permission set group bundles several permission sets into a role-shaped package you assign as one unit. A muting permission set, created inside a group, subtracts specific grants where the group gives a persona slightly too much.

The trap is sprawl. Move carelessly and you replace one-profile-per-user with one-permission-set-per-user, which the community has a name for now: permission set explosion. You have not fixed anything. You have moved the tangle and added objects.

The pattern that avoids it is persona-first. Design permission sets around capabilities, a small “Case Management” set, an “Export Reports” set, group them by role into permission set groups, and use muting for the exceptions instead of cloning a whole new set for one person. If your permission set count starts tracking your user count, stop and redesign. The goal is fewer, composable pieces, not more.

How to migrate without a deadline

There is no single “Migrate to Permission Sets” button in Setup. The tool Salesforce actually ships is the free User Access and Permissions Assistant, a Salesforce Labs app you install from AppExchange. Its converter turns a profile into an editable permission set so you are not rebuilding by hand. Note the gap: the conversion excludes record types and tab access, so you handle those separately.

Start by reading what you have. The trick most admins miss is that every profile has a hidden permission set behind it, flagged IsOwnedByProfile, so you can query the real, standalone sets and tell them apart:

-- Real, assignable permission sets, not the ones backing profiles
SELECT Id, Label, Type FROM PermissionSet WHERE IsOwnedByProfile = false

-- Who is assigned what
SELECT Assignee.Name, PermissionSet.Label, PermissionSet.IsOwnedByProfile
FROM PermissionSetAssignment
WHERE PermissionSet.IsOwnedByProfile = false
ORDER BY Assignee.Name

-- Custom permissions and tabs granted, by permission set
SELECT Parent.Name, SetupEntityId, SetupEntityType
FROM SetupEntityAccess
WHERE SetupEntityType IN ('CustomPermission','TabSet')
  AND Parent.IsOwnedByProfile = false

If you work through source control, know how profile metadata behaves, because it is the most common way a migration goes wrong. A retrieved .profile file only contains object and field permissions for the objects and fields that are also in the same retrieve. Pull a profile alone and you get an almost empty file that looks like the permissions vanished.

# A profile retrieved alone is nearly empty — include the objects too
sf project retrieve start \
  --metadata "Profile:Sales User" "CustomObject:Opportunity" "CustomObject:Quote" \
  --target-org prod

Deployment runs the other way. A profile deploy is an overlay that applies whatever is in the file, so a partial profile can silently strip permissions you never meant to touch. Test profile and permission-set changes in a sandbox the same way you would test any metadata change through a release pipeline, and diff before you deploy.

Automate the assignment, within its limits

Once access lives in permission sets, the next question is who gets which set, and doing that by hand is where perm-set estates rot. User Access Policies automate it. A policy assigns or removes permission sets, permission set groups, permission set licenses, and package licenses, and adds users to public groups and queues, based on criteria on the user record.

It has been generally available since Summer ‘24, and the cap on active policies was raised from 20 to 200, so it can carry a real org. Two limits are worth designing around. Policies do not chain, so one policy’s action cannot trigger another. And a policy runs either automatically on user create and update, or manually when an admin runs it, which makes the manual mode a decent tool for a one-time backfill during migration.

Used well, this closes the loop the old model never could. A new hire’s department and role drive their permission set groups on day one, and the same criteria pull the access back when they move teams. That is the joiner-mover-leaver hygiene that access reviews keep flagging, done by policy instead of by ticket. It is also part of the same discipline as governing which user your agents run as, since an Agentforce agent is bound by exactly the permissions its running user holds.

What I would do this quarter

The reprieve is a gift only if you use it as one. Gartner’s read on the reversal, as reported by Salesforce Ben, is that permission modernization is hard to justify as a standalone project. The read is right, and that is also why it never gets done. Fold it into work that is already happening.

Bundle the permission cleanup into your next security review or your next release, not a separate initiative with its own budget that will lose the argument. When you touch a profile for any reason, move its portable permissions to a persona permission set and leave the shell behind. Run the org health scorecard to see how much access debt you are carrying, and if the estate is large, treat it as technical debt paid down incrementally rather than in a big bang.

The deadline was doing you a favor by forcing the conversation. Now that it is gone, the orgs that keep moving will pull further ahead of the ones that exhale and stop, and the gap shows up on the day someone asks who can see what.

Understanding the basics

Are Salesforce profiles going away in 2026?

No. Salesforce cancelled the planned retirement of permissions on profiles in June 2026, so profiles keep working and nothing is being force-migrated. Salesforce still recommends managing access through permission sets and permission set groups, but there is no longer a deadline forcing the move.

What is the difference between a profile and a permission set?

A profile is a one-per-user baseline that now mainly holds settings with no other home, such as login hours, IP ranges, default record types, and page layout assignment. A permission set is a scoped grant you assign and revoke independently and can report on, which is why object, field, and system permissions are better managed there.

Should you still migrate from profiles to permission sets?

For most orgs, yes, on your own timeline. The security and reporting benefits of permission sets are unchanged by the cancelled deadline, and Salesforce continues to invest only in the permission-set model. Fold the work into existing security reviews and releases rather than running it as an urgent standalone project.

What automates permission set assignment in Salesforce?

User Access Policies, generally available since Summer ‘24, assign and remove permission sets, groups, and licenses based on criteria on the user record, up to 200 active policies. Policies cannot trigger each other, and they run either automatically on user changes or manually for one-time backfills.

The debt outlived the deadline

A cancelled deadline is easy to hear as permission to stop. The opposite is true. The permissions you meant to move are still on the profiles, still hard to audit, and still growing.

Move them because a permission set answers “who can do this, and why” and a profile does not. Do it in the seams of work you were doing anyway, and skip the fire drill you no longer have to run.

Sitting on a pile of profiles you were about to migrate and now are not sure whether to? Talk to us, we untangle access models as part of an org health pass.