Salesforce Cancelled the Profile Permissions Retirement: What to Do Now

Somewhere in your backlog there is an epic called "Profile to [Permission Set](/terms/permission-set) Migration" with a due date built around Spring '26. Maybe it is 60% done. Maybe it never started because the deadline felt soft after 2024. Either way, in July 2026 a colleague sent you the Salesforce Ben link with three words: "so, never mind?"

Salesforce cancelled the retirement of permissions on Profiles. Not postponed. Cancelled, in a quietly updated Knowledge article that most admins found out about from community coverage rather than from Salesforce. That leaves every org with a half-finished migration, a stalled one, or a finished one, and the same question in all three cases: what do we actually do now?

This post is the answer for practitioners. The timeline as it really happened, the feature gaps that killed the plan, what the community reaction tells you about the risk of building on vendor deadlines, and a migration playbook that works whether or not Salesforce ever names a new date.

What was announced, and what was un-announced

The original plan dates to January 2023. Salesforce's Spring '23 Learn MOAR content named Spring '26 as the end-of-life release for permissions on Profiles. Profiles would survive as a container, but the checkboxes admins have clicked since the Classic era, object permissions and field-level security chief among them, would stop living there. All of that would move to Permission Sets and Permission Set Groups. Three years of runway. A real date. Roadmap slides across the ecosystem were rebuilt around it.

The first walk-back came in 2024. Cheryl Feldman, the Director of Product Management who owned the change, told the community that Salesforce would "no longer enforce the Spring '26 end-of-life date" while still recommending the permission-set-led model. Direction unchanged, clock stopped. Most teams read that as a delay and kept a migration line item on the roadmap, waiting for the replacement date.

The replacement date never came. Instead, Knowledge Article 003834041 got a rewrite, dated June 6, 2026, with the title "Permissions in Profiles Retirement Cancelled" and one load-bearing sentence: the enforcement "has now been cancelled based on customer feedback and remaining feature gaps." No release note callout, no email, no keynote slide. Salesforce Ben spotted the edit and broke the story on July 9, which is how a five-week-old policy change reached most of the people it affects. We covered the announcement itself in our July 9 news post; this article is about what you do next.

Two things are true at once, and both matter for your planning. The forced retirement is dead. The recommendation is not. Salesforce still tells you to run a permission-set-led security model with least privilege as the goal. What changed is the enforcement mechanism, which went from "platform deadline" to "your own discipline."

Why the retirement actually collapsed

The official reason names two causes, and they compound each other.

Adoption never got close. The Salesforce Ben Admin Survey found that only 20.5% of organizations had fully moved to a Permission Set-led model, three years after the announcement and months from the original deadline. You cannot flip a switch that strands four out of five customers. Whatever the messaging says, that number alone made Spring '26 enforcement impossible.

The tooling could not receive the migration. This is the more damning half, because it explains the adoption number. Permission Sets still cannot own everything a Profile owns:

• Record Type access migrates awkwardly. You can grant record type visibility through a Permission Set, but default record type selection stays a Profile concept. An org with heavy record type usage cannot express its full model in Permission Sets alone.
• App defaults are Profile-bound. Permission Sets can make an app visible, but the default app a user lands in after login is still set on the Profile.
• Page layout assignment never moved at all. Layout assignment is a Profile-plus-record-type matrix, and the successor story, Dynamic Forms plus dynamic related lists and actions, covers real ground but not all of it. Orgs with hundreds of layout assignments had no clean landing zone.

Add login hours, login IP ranges, and password policies, which were always going to stay on Profiles, and the "retirement" was never going to produce Profile-free orgs. It was going to produce a hybrid, with the awkward parts unsolved. Asking every customer to finish a migration the platform itself could not fully absorb was the actual design flaw, and cancelling was the honest correction. Painful, but honest.

There is a lesson here worth keeping for every future deprecation notice: check whether the destination is finished before you commit to the moving date. The orgs that got burned worst were the ones that migrated fastest into the gaps.

What the community reaction tells you

The dominant reaction was not relief. It was resignation. Practitioners called the reversal "pretty typical for Salesforce rollouts," one solution architect summarized the whole arc as "a big mess," and Salesforce itself acknowledged in the coverage that "this change in direction may be frustrating for customers and partners who invested time preparing." That acknowledgment is unusual, and it hints at how much partner-delivered migration work is now stranded.

Look closer, though, and the practitioner consensus splits from the emotional one. Almost nobody in the community coverage advises rolling back to Profile-based permissions. The recurring advice is the opposite: "permission set all the things," as one technology manager put it, because Permission Sets and groups remain the better mechanism for object access regardless of the vendor's calendar. One MVP noted the retirement is still on the long-term roadmap in spirit, just without a date. Salesforce's own product investment keeps flowing toward Permission Sets, User Access Policies, and the access-summary tooling, not toward Profile enhancements.

So read the community signal as two separate findings. Finding one: trust in Salesforce end-of-life dates took real damage, and your next business case cannot lean on a vendor deadline. Finding two: the technical direction is unchanged and uncontested. Plan with both in mind.

Keep migrating or pause? A decision framework

The wrong move is deciding by mood, either "the deadline is gone so the project dies" or "we said we would finish so we finish." The right move depends on where you are and why you started. Three situations cover almost everyone.

You finished the migration. Nothing changes. You are running the model Salesforce still recommends, your access grants are auditable one Permission Set at a time, and you get to skip whatever the next enforcement drama turns out to be. Resist any suggestion to "simplify back" onto Profiles. That is rework in the wrong direction.

You are mid-migration. Keep going, but change the sequencing logic. With a deadline, the rational order was "whatever gets us compliant fastest." Without one, the rational order is risk-first: migrate the profiles attached to finance users, integration users, and anyone with data export or modify-all style permissions before you touch the low-risk bulk. Drop any workaround you built purely to hit the date, especially hacks that force-fit record types or app defaults into Permission Sets. Those gaps are now officially Salesforce's problem to close, and your workaround will fight the eventual native solution.

You never started. Do not celebrate yet. The reasons to migrate were never really about the deadline. A Profile is one object granting dozens of unrelated permissions to every user assigned to it, which makes least privilege nearly impossible to maintain at scale. A Permission Set is a scoped grant you can assign, report on, and revoke independently. If your org has more than a handful of custom profiles, you have an access-sprawl problem today, cancelled retirement or not. Start small and start with the audit below.

The one genuinely new input is for regulated orgs. If a SOX control, an ISO 27001 remediation item, or a pen-test finding cited "migrate off Profile permissions by Spring '26," that line item lost its external forcing function. The finding underneath it, usually over-broad access, did not go anywhere. Re-anchor the control to least privilege rather than to a vendor date, and expect the budget conversation to get harder before it gets easier.

Audit your Profile permission debt first

Whichever branch you are on, the next concrete step is the same: measure how much permission logic still lives in Profiles. Most orgs guess. You can know, because every Profile secretly stores its permissions in a hidden Permission Set the platform manages for it, and that object is queryable.

Start with the inventory:

SELECT Id, Profile.Name
FROM PermissionSet
WHERE IsOwnedByProfile = true

Every row is a Profile wearing a Permission Set costume. Then measure what those Profile-owned rows actually grant:

SELECT Parent.Profile.Name, SobjectType,
       PermissionsRead, PermissionsCreate,
       PermissionsEdit, PermissionsDelete
FROM ObjectPermissions
WHERE Parent.IsOwnedByProfile = true
ORDER BY Parent.Profile.Name, SobjectType

Run the same shape against FieldPermissions for field-level security. The result set is your debt register: every object and field grant that would need a Permission Set home. Sort it by profile and you will usually find the classic distribution, two or three giant profiles carrying most of the debt and a long tail of near-empty clones somebody created for one exception in 2019.

Two free tools shorten the analysis. The User Access and Permissions Assistant on AppExchange bundles an analyzer, a reporter for compliance-ready output, an assignment manager, and a recommender that suggests how to convert Profile permissions into Permission Sets. And the User Access Summary on the user detail page answers the perennial "why can Dana delete Opportunities?" question in one click instead of a forty-five minute archaeology session across profile, groups, and sets.

Close the audit by scoring each profile on two axes: how much it grants (the query output) and who holds it (admins, integrations, and finance score high). That two-axis score is your migration order, and it is a better one than the deadline ever gave you.

The reversal-proof migration plan

The five-step path Salesforce documents alongside the cancellation is still the right skeleton: document current grants, design the Permission Set structure, automate assignment, validate, roll out. What needs to change is how you run it, because the last three years taught a specific lesson about betting on vendor timelines. Build the plan so it pays off even if Salesforce changes direction again, in either direction.

Anchor the business case to your own risks. Write the goal as "no user holds a permission their role does not require" and tie it to your last access review findings, not to any Salesforce article. A goal you own cannot be cancelled by a Knowledge article edit.

Migrate access, leave settings. Move object permissions, field-level security, user permissions, custom permissions, and tab visibility into Permission Sets and groups. Leave what Profiles still do best on the Profile: default record types, app defaults, page layout assignment, login hours, IP ranges, password policies. This is exactly the hybrid Salesforce now describes, and it means you never build in the gap zones that killed the retirement in the first place.

Ship one profile at a time. Pick a profile, build its Permission Set Group equivalent, assign both in a sandbox, and diff effective access before touching production. Each converted profile is independently valuable. If priorities shift after profile six of twenty, you keep six wins instead of one stranded program. Big-bang cutover weekends were always the deadline's fault; you no longer have that excuse.

Automate assignment from day one. User Access Policies, GA since Summer '24, can assign Permission Sets and groups automatically based on user criteria and migrate existing populations in bulk. Manual assignment is where permission-set models rot back into sprawl, one onboarding ticket at a time.

Write down the why. For every Permission Set you create, one line: what it grants and which roles need it. When the next reversal, re-announcement, or reorg arrives, the org with documented intent adapts in a sprint. The org with ten thousand undocumented checkboxes starts over.

If you want the full conceptual grounding for the target model, the mnemonic and the minimum-access pattern live in our Profile vs Permission Set vs Permission Set Group guide, and the record-visibility half of the story is in the sharing and visibility guide. This playbook is the sequencing layer on top of those.

What to watch between now and the next announcement

The cancellation article is a snapshot, not a treaty. Three signals will tell you where this goes next.

Watch release notes for the gap features. If record type access, app defaults, or layout assignment ever land natively in Permission Sets, that is Salesforce quietly finishing the destination, and a re-announced retirement becomes plausible. Sandbox preview windows are the cheap place to test each drop; our Winter '27 sandbox preview guide covers how to run that motion.

Watch where new features attach. Every recent access-control investment has landed on the Permission Set side of the house. The day a genuinely new capability ships Profile-only, the strategy has changed again and it is time to re-read the tea leaves.

And watch your own org's drift. Without a deadline, the quiet failure mode is new projects defaulting back to "just add it to the profile" because it is one click. A quarterly run of the two audit queries above is enough to catch the backslide early.

The deadline is gone. The work it pointed at is not. This week, run the IsOwnedByProfile inventory query, count the profiles still carrying object or field permissions, and put your three highest-risk ones at the top of next quarter's plan. Salesforce's calendar stopped being your forcing function in June. Your audit log is a better one anyway.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.