Profiles Keep Their Permissions

Salesforce cancelled the retirement of permissions in profiles. Not delayed again, not softened with a new target date. Cancelled, in a Knowledge article nobody sent an email about, updated sometime last month with no press release and no Trailhead badge to mark the occasion. Salesforce Ben caught the edit and published it on July 9. Here is what the reversal actually undoes, and what to do with the migration work you already started on the strength of a deadline that turned out not to exist.

If you have not been tracking this one, the short version: since January 2023, Salesforce had an official end-of-life date for assigning permissions directly on a Profile. Object permissions, field-level security, the checkboxes admins have clicked since the Classic era, all of it was supposed to move exclusively to Permission Sets and Permission Set Groups by Spring '26. That date is gone. Not pushed to Winter '27. Gone, with nothing in its place.

Three years, two walk-backs

Trace the actual dates and the pattern gets uncomfortable fast. January 2023: Salesforce's Learn MOAR Spring '23 content names Spring '26 as the end-of-life release for permissions on profiles. Profiles would keep existing as a record, but the checkboxes for object and field permissions would stop working there. Everything moves to Permission Sets. Admins had a little over three years to migrate, which sounded workable at the time.

By 2024, the first crack showed. Cheryl Feldman, Director of Product Management, told the community Salesforce was "no longer going to enforce the Spring '26 end-of-life date," while still recommending a permission-set-led model as the right long-term architecture. That is a soft walk-back. The direction stayed the same, only the clock stopped. Plenty of admins reasonably read that as "the deadline moved," not "the deadline is meaningless," and kept planning around some future date Salesforce would eventually name.

That future date never arrived. Instead, the Knowledge article got a quiet rewrite. The current text: "This enforcement has now been cancelled based on customer feedback and remaining feature gaps." No modal on login, no release note callout, no email to admins who had opened cases asking when the real date was coming. You had to go looking for it, and most people did not, which is exactly why a July 9 blog post is still breaking this as news five weeks after the article changed.

Why it actually broke

Two reasons, and they are not the same problem wearing two names. First, adoption never got close to done. Salesforce Ben's own Admin Survey found that only 20.5% of organizations had fully transitioned away from profile-based permissions into a Permission Set-led model, more than three years after the original announcement and months from the deadline it was supposed to hit. Roughly four out of five orgs were still, in some meaningful way, running on the thing being retired.

Second, and more damaging to Salesforce's own case: the tooling was not actually ready to receive that migration at scale. Permission Sets still cannot own everything a Profile owns. Record type access has gaps. App defaults are awkward to replicate outside a profile. Page layout assignment stayed tied to profiles rather than moving cleanly to Permission Sets, Dynamic Forms, related lists, or actions, the very features Salesforce pointed to in 2023 as the future. Permission Set Groups close some of that distance, not all of it. Asking every customer to finish a migration the platform itself could not fully support was never going to end in a clean cutover, and eventually somebody at Salesforce did the math on that and pulled the plug instead of the trigger.

The model Salesforce actually wants now

Cancelling the deadline did not cancel the architecture. Read past the headline and the updated guidance is a hybrid, not a retreat to Profiles-for-everything. Profiles keep the baseline settings a user needs to function: assigned apps, default record types, page layouts, login hours, IP ranges, password policies. Permission Sets and Permission Set Groups keep the access control layer: object permissions, field-level security, user permissions, custom permissions, tab visibility. That is close to where well-run orgs already sat before any of this started, and it is a more honest description of what "least privilege" has meant in practice for years.

The recommended migration path Salesforce documents alongside the cancellation is unchanged in substance: document what each profile currently grants, design the equivalent Permission Set and Permission Set Group structure, automate assignment with User Access Policies instead of manual clicks, test in a sandbox, then roll out to production. None of that got easier or harder this week. What changed is the reason to do it. It used to be a deadline. Now it is just good practice, which is a weaker motivator and also the more honest one.

The credibility problem nobody at Salesforce priced in

Here is the part that outlasts the policy change itself. Salesforce Ben frames this as the platform's first full cancellation of a retirement, as opposed to the more familiar pattern of pushing a date out and keeping the destination fixed. Whether or not it is technically the first, it reads that way to admins who have now watched a three-year deadline dissolve into nothing with two separate walk-backs along the way. One frustrated admin's read, quoted in the coverage: "the goal posts must not change." Another line from the same piece cuts closer: admins spent "two years making a judgment call Salesforce could have just, in writing, made solid back then."

That is the actual cost of this reversal, and it has nothing to do with permission architecture. It is a trust problem. MFA enforcement went through its own rocky rollout earlier this year, and Salesforce has retired certifications before without this kind of reversal. A cancelled security deadline is a different animal from a certification sunset. Every future Salesforce end-of-life notice now carries an implicit asterisk for anyone who lived through this one: maybe, maybe not, check back in three years. That asterisk makes the next real deadline, whatever it turns out to be, harder to get organizations to take seriously, which is the opposite of what a security-motivated retirement is supposed to accomplish.

There is a quieter version of this problem for anyone running a regulated org. If your SOX controls, your ISO 27001 remediation plan, or your last penetration test writeup listed "migrate off profile-based permissions by Spring '26" as a scheduled control, that line item just lost its external forcing function. Auditors do not generally accept "Salesforce cancelled the deadline" as a reason to close a finding, especially when the finding was really about access sprawl rather than about compliance with a vendor's calendar. Anyone who leaned on the EOL date to get budget or headcount approved for this work should expect that argument to get harder, not easier, in the next planning cycle. The underlying risk did not shrink. The easiest sentence for justifying the spend just did.

What to actually do with the migration you already started

If you are in the 20.5% who finished, nothing changes. Keep going the way you were going. If you are in the larger group that started and stalled, or never started because the deadline felt soft after 2024, the calculation is simpler than it looks. The security argument for Permission Sets over Profiles was never really about a Salesforce deadline. A Profile is a single object granting dozens of unrelated permissions to everyone assigned it, which makes least-privilege access nearly impossible to enforce cleanly at scale. A Permission Set is a scoped grant you can assign, audit, and revoke independently. That argument was true in 2023, it is true today with no deadline attached, and it will still be true whenever Salesforce names a new one, if it ever does.

So treat the cancellation as removing a false urgency, not removing the reason. Run the same five steps the Knowledge article still recommends: document current profile-based grants, design the Permission Set and Permission Set Group equivalent, automate assignment through User Access Policies, validate in a sandbox, then cut over in production, one profile at a time rather than one big-bang weekend. Without that structure in place, an org is not compliant with a retired policy so much as it is waiting for a compromised credential to find the widest door in the building.

What to do next

Pull up your org's profile list this week and count how many still carry object or field permissions instead of relying on Permission Sets. If that number is close to zero, you are done, deadline or not. If it is not, pick your three highest-risk profiles, the ones tied to finance, admin, or integration users, and migrate those first regardless of what Salesforce's calendar says. The deadline that made this feel urgent is gone. The reason it was ever a good idea never was.

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.