Admins

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

By Andrew Cook

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.

READ MORE: User Access Policies (Beta)

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.

The Author

Andrew Cook

Andrew is 14x certified and has worked in the ecosystem for 12 years.

Comments:

    Sjoerd Woltjer
    March 11, 2024 1:56 pm
    'Permission Set Groups allow Permission Sets to be grouped together and assigned to Users.' You mean a bit like.. a profile? I really don't see the advantage of moving from profiles to permission sets. If you don't think really well about base level permissions for your user population, it will be a mess irregardless if you use profiles or permission sets. The knowledge and experience of the admin is key here, not tooling.
    Mark
    September 11, 2024 3:38 pm
    The obvious advantage is that the relationship between a user and a profile is one to one. A user can only have one profile which inevitably leads to stacking permission sets onto them to grant them extra access, whether temporary or permanent. As soon as you do this you now have to manage your access in two places for that user, and of course you also have access for the same item (such as an object) probably managed in two places, profiles for some users and permission sets for others. All of this increases the complexity of managing permissions, increases the workload for an admin, and makes errors more likely. Permission set groups on the other hand can be stacked many to one against a user, so you can create a permission set group for a role or job function (or however you want to break it down), and assign as many of those as you want to a user. All your permissions are managed in the same place, and unlike with profiles because you can assign many, you can name them in a way that describes what access it's granting, which makes reviewing access and troubleshooting much easier. No tool can make a bad admin into a good one, but a better tool will make it easier to manage these things.

Leave a Reply