For three years, the standard advice was "get off profile permissions before Spring '26." The date has now come and gone, and Salesforce has quietly changed the story. If you spent the year dreading a forced migration, or you ignored the warning and hoped it would go away, here is where things actually stand and what is still worth doing.
What Salesforce announced, and what changed
The timeline, as reported by Salesforce Ben and others:
- January 2023: Salesforce announced that permissions on profiles would reach end of life, targeting the Spring '26 release. Object and field permissions, user permissions, tabs, Apex class access and custom permissions were all meant to be granted through permission sets only.
- 2024: Cheryl Feldman, Director of Product Management, said Salesforce was no longer going to enforce the Spring '26 date, while still recommending a permission-set-led model.
- June 2026: The Salesforce Knowledge article on the topic (ID 003834041) was updated to say the retirement has been cancelled. The reasons given are customer feedback and remaining feature gaps. Salesforce Ben, which reported the change in July, adds that tooling was not ready for a clean migration at scale, and cites its own admin survey in which only 20.5% of organisations had fully moved to a permission-set-led model.
One caution on sourcing: we could read only the secondary reports of that Knowledge article, not the article itself. Sources also differ on the wording ("cancelled" versus "indefinitely postponed"). Neither version comes with a new date. Check the article directly before you quote it in a change request.
What has not changed
The cancellation removes the deadline. It does not remove the reasons for the deadline.
- Profiles get no new investment. Salesforce's energy goes into permission sets and permission set groups. A profile-only model will fall further behind the platform each release.
- Least privilege is still the recommendation. Salesforce still describes a permission-set-led model as best practice, and its advice is to keep migrating what you can.
- The practical problems with profiles are the same. A profile is one bundle of everything. Two sales teams with slightly different needs become two near-identical profiles, and a year later nobody can say how they differ.
How the two models actually work
A profile is the base. Every user has exactly one, and it is tied to their user licence. Whatever is granted on the profile, the user has.
A permission set is additive. It adds access on top of the profile and never takes it away. This is the source of the classic admin surprise: removing a permission from a permission set does not help if the profile, or a second permission set, still grants it. Access is the union of everything the user holds.
A permission set group bundles several permission sets into one assignable unit, such as "Service Agent" or "Finance Approver." It is how you keep assignments readable once you have more than a handful of permission sets.
A muting permission set lives inside a permission set group and turns off selected permissions for that group's members only. Per Salesforce's Trailhead module:
- It affects only users assigned to that group, not people who hold the same permission set directly.
- It does not remove a permission the user gets from somewhere else, such as their profile or another group.
- Muting one permission also mutes the ones that depend on it. Muting Read also mutes Create, Edit and Delete.
- A group can have only one muting permission set.
That second point is the one to remember. Muting is a way to trim a group, not a way to override a profile.
What still lives on the profile
Even in a permission-set-led org, the profile does not become empty. Based on Salesforce Ben's reporting, plus Salesforce's training material, these are the awkward areas:
- Login IP ranges and login hours. Salesforce Ben's example is regional sales profiles that differ only by IP range. The common permissions can move to a permission set, but the regional base profile stays.
- Page layout assignments. Dynamic Forms, related lists and actions cover a lot of what layouts do, but existing layout assignments are still per-profile.
- Default record types and default apps. These are repeatedly named as the gaps that complicate a permission-set design.
We found these on third-party and training sources rather than a Salesforce page we could open, so confirm the list against Salesforce Help for your release before you design around it.
A migration plan that does not break anyone's access
You do not need a deadline to benefit from this. You need a sequence that is safe to stop halfway.
1. Start with a minimal base. Create a small number of base profiles, ideally one per licence and per login restriction you genuinely need (for example, one per IP range). Strip everything else off them over time.
2. Inventory what each profile really grants. Before you move anything, list the object permissions, field permissions and system permissions on each profile. Look hardest at the high-risk ones: Modify All Data, View All Data, Author Apex, Manage Users. These are the permissions your last security audit will ask about anyway.
3. Build permission sets around jobs, not people. "Can approve invoices" is a good permission set. "Sarah's access" is not. Aim for sets that each do one thing, then combine them into groups that match real roles.
4. Move one team first. Pick a team with a clear job, build their permission set group, assign it, then remove the equivalent grants from their profile. Test with a real user's view, not an admin's.
5. Remove from the profile last, and in small steps. Because access is a union, adding a permission set is safe. Removing from the profile is where things break. Do it in a sandbox first, one object or one system permission at a time.
6. Use the tools Salesforce built for this. Per Salesforce Ben, User Access Policies (turned on under User Management Settings in Setup) let you find users by profile and assign them to permission sets or groups automatically. The free User Access and Permissions Assistant adds an analyser, reporter, manager and recommender.
7. Write down your rule for new access. "New access goes in a permission set, never on a profile" is a rule that stops the problem getting worse while you work through the backlog.
Where the manual work bites
The step that takes the time is not the thinking. It is Setup. Profiles and permission sets are edited one at a time, a save can be rejected because of a dependency you did not know about (Delete needs Read and Edit), and comparing two profiles means opening two tabs and squinting.
This is what the Permissions Workbench in orgadmin.ai is for. It puts profiles and permission sets side by side as columns in one matrix, with object permissions (Create, Read, Edit, Delete, View All, Modify All) and field-level security in the same view. You stage changes across several of them at once, review the full diff in plain language, and apply it as a background job with per-row results. Salesforce's dependency rules are applied as you click, so ticking Delete brings Read and Edit with it. It can also create a new permission set by cloning every grant from an existing one, which is a quick way to start the "carve a job out of a profile" step above.
It does not replace your judgement. Applying changes needs an owner or admin role, writes must be enabled on the deployment, and every write is audit-logged. A change builder that can only touch permission records means a mistake there cannot reach your business data.
If you only want the audit half, the Security Review has a permissions hygiene module that flags over-permissioned profiles and stale integration users. How often to run it is covered in How often should you audit Salesforce security?.
A short checklist to take away
- Confirm the current status in Knowledge article 003834041 and note the date you checked.
- Count how many profiles you have and how many differ only slightly.
- List every profile that grants Modify All Data or View All Data, and decide whether each still should.
- Pick one team and one permission set group to pilot.
- Adopt the rule: new access goes in permission sets.
- Keep login-IP and page-layout profiles where Salesforce still requires them, and document why.
The takeaway
The deadline is gone, and so is the excuse. Salesforce still builds for permission sets, still recommends them, and still gives profiles no new features. Treat the cancellation as extra time, not a verdict. A migration you do in small safe steps over a quarter is far better than one you rush the month someone fails an audit.
Facts in this article were checked on 9 October 2026. Salesforce changes these pages without notice, so verify anything you plan to rely on.