Salesforce recently announced that the Spring ’26 release would mark the end of life (EOL) for permissions on profiles.
Cheryl Feldman (Product Manager at Salesforce) who is the pioneer behind this big transformation had something to say on her blog. Let’s dive into it.
What is a profile?
A user’s capabilities within Salesforce are determined by their profile, which is a set of preferences and permissions. A profile manages “Object permissions, Field permissions, User permissions, Tab settings, App settings, Apex class access, Visualforce page access, Page layouts, Record Types, Login hours & Login IP ranges,” among other things.
What are permission sets?
The permission set and profile are strikingly similar. Object permissions, Field permissions, User permissions, Tab settings, App settings, Apex class permissions, and Visualforce permissions are just a few examples of the things you can manage at profiles and you can manage them here as well. However, the primary distinction between these two is that a person can only have one profile and several permission settings active at once.
As a result, we may create profiles that provide the bare minimum of settings and rights for each type of user, and then use permission sets to provide more access.
What information will remain on a profile?
- One-on-one interactions
- Login times/IP addresses
- Record kinds and apps are the defaults.
Salesforce will not invest in adding page layout assignments to permission sets because the future is App Builder/Dynamic Forms.
After EOL, what will be available exclusively on permission sets?
- Permissions for users (system and app permissions)
- Permissions for objects (object Create, Read, Update, and Delete [CRUD])
- Permissions for fields (field-level security [FLS])
- Tabs
- Types of records (not defaults)
- Apps (not defaults) (not defaults)
- Access to connected apps
- Classes at the pinnacle
- Pages created with Visualforce
- Individual permissions
How should user profiles be migrated to permission sets and permission set groups?
User Access Policies is a feature in Closed Beta (as of Spring ’23) that allows you to establish criteria about your users — either user attribute or entitlement based — to assist you in migrating them.
For the Spring release, User Access Policies will continue to be in Closed Beta;
However, Salesforce has made several advancements, with 20 active user access policies being one of them. If you want to test out this feature, please fill out this form since they accept most clients with Unlimited Edition or Enterprise Edition orgs. Users can deploy user access policies using first-generation and second-generation packaging thanks to the Tooling API and the Metadata API they’ve also made available. They made the material available early in Help & Training because this is a high-visibility feature and many customers are starting to shift away from profiles.
You can disable the filter that only displays permission sets with at least read access to the object where you’re creating or editing the field in the Spring ’23 version. Salesforce also made the columns sortable and added more columns to assist you to find the appropriate permission set. Additionally, they display a notice with a link to create a permission set if you’re in a new org with this setting enabled and don’t have any.