Salesforce to Retire Permissions on Profiles – What’s Next?

Salesforce has officially announced that permissions on profiles have an end-of-life date. Retirement is due in the Spring ‘26 release, so there is still plenty of time to properly plan how you’re going to implement these changes.

In this article, we’ll be looking at why this is happening, what the future looks like for profiles and permission sets, and what you can do to get started in preparing for the future of your user management.

Why Is This Happening?

To put it simply, because managing permissions is a bit of a mess! Most admins out there will agree with this, as permissions on profiles can make managing users extremely difficult for some orgs. 

Cheryl Feldman, Director of Product Management at Salesforce, has been the driving force behind this change. Cheryl made a point of reaching out to many admins when she started her role at Salesforce to identify the true pain points they face. And surprise surprise, user management was right up there! 

Since then, Cheryl has worked tirelessly to move permissions away from profiles into something more manageable – something that is easier for admins to manage overall.

Are Profiles Dead?

Profiles aren’t going away. When setting up a user we will still need to select a profile, and there are a number of things that will remain on the profile:

• One-to-one relationships: Login hours/IP ranges.
• Defaults: Record types, apps.
• Page layout assignment: The future is App Builder/Dynamic Forms, so Salesforce will not invest in bringing page layout assignment to permission sets.

This means that the very base permissions will still be managed via the profile. They aren’t dead, but they aren’t going to be as important as they were previously.

What Is Moving to Permission Sets?

The following permissions that were previously managed via the profile will be moving into Permission Sets after the Spring ‘26 release:

• User permissions (system and app permissions)
• Object permissions (object Create, Read, Update, and Delete [CRUD])
• Field permissions (field-level security [FLS])
• Tabs
• Record types (not defaults)
• Apps (not defaults)
• Connected app access
• Apex classes
• Visualforce pages
• Custom permissions

Permission Set Groups

As outlined by Bill Appleton in this Introduction to Permission Set Groups, Permission Set Groups allow Permission Sets to be grouped together and assigned to Users. This reduces the dependency on Profiles and provides greater clarity and agility for all permission assignments.

In short, Permission Set Groups allow you to base your permissions around a User’s job function.

What Can I Do Now?

As of Spring ‘23, there is a closed beta for User Access Policies which is a way of migrating your user profiles to Permission Sets and Permission Set Groups. You can participate in this closed beta here.

You can also take advantage of the User Access and Permissions Assistant on the AppExchange. This free app gives admins the ability to analyze, report, and manage permissions and permission assignments.

Finally, check out our Clean Up Profiles and Permission Sets in Salesforce article by Joseph Rishe for some really useful tips on how to get started cleaning up your existing Profiles and Permission Sets.

Summary

There’s no hiding from it, this change is a big deal. But it’s definitely a change that’s needed. As admins, we need to embrace changes like this – changes that, on the outset, look quite daunting, but in the long run, will make our lives so much easier. 

Spring ‘26 is a long way away, so we have plenty of time to get our heads around it, but you don’t have to wait until then to start making changes.