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

Share this article...

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.


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.

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

  1. Thanks for the article! The ‘User Access and Permissions Assistant’ is great to create a permission set from a profile but what is missing is an easy way to clean afterwards the profile from all the permissions ‘transferred’ to the permission set.

    1. I am looking for exactly this! A way to remove all the permissions which are currently in the profile.
      If one found an easy way, it would be great to share it here! 🙂

  2. Just one comment: How will this (properly) work with User Provisioning as a Profile is one-to-one for a user but permission set (group)s are many to be provisioned.

  3. This makes me happy! TBH, I got great experience learning the admin side before I knew what that was because somehow I had too much access lol. There error started my career. I will admit that managing access can be a nightmare with all the different options so I’m glad they’re updating this

  4. Hi, thanks for this article. Currently I’m using conditions based on profile name to display or not display actions in the highlight panel. You said “The future is App Builder/Dynamic Forms” so, if the objective is to no longer use old page layouts, I guess there should be a way to get permission sets as conditions in action visibility formulas, but currently we can’t. That’s why I’m not ready to migrate currently.

    1. Laure, Consider creating custom permissions that grant access to the actions. You won’t need to know which profile/permission sets a user has, only if they have the appropriate permission.

  5. Is there any word on whether or not SF will be providing out of the box permissions to replace the permissions currently part of the profiles they provide?

  6. Lets wait and see, we can’t do anything about it except to change provider. I believe the need for this change is resulted out of the lack of knowledge of how it works
    Roles and Profiles has been the cornerstones of user access for Salesforce, So each department in the business got a very well planned and dedicated Profile.
    Later back in the days , Salesforce introduced Permission sets to remove the need to create a new profile for a single user inside a profile who needed some extra permission.

    Out of my experience I have seen many admins who instead of planning for Profiles just miss-used the permission set, which in return made the whole administration for the user access more complex as nobody knew anymore why a certain user got access to something they shouldn’t, because there was out of the sudden just one profile but 50+ permission sets.

    Now, if the plan goes ahead , we as Admins need to maintain 1000s of permission sets due to custom objects and field level security
    adding the permission set groups on top of that , makes it near impossible to trouble shoot access issues due to the fact that permission sets in a group are assigned to the group and not the user.

    If that user access policies is about grouping users to then assign permissions its only adds a layer of admin as the profile still stays?
    I have seen ORG’s with 500+ fields on objects and 100’s of Objects , multiply that with big businesses with the odd 12k users or even smaller ones with just 2000 users, happy permissions setting

Add Comment