Salesforce Announced The End of Life of Permissions on Profiles | The Developer Guide
The time has finally arrived when Salesforce recently announced that the Spring '26 release would mark the end of life (EOL) for permissions on profiles. What does this mean and what is in store for us? Let’s find out in this blog inspired by Cheryl Feldman (Product Manager at Salesforce) who is the pioneer behind this big transformation. Cheryl has been working consistently on this for the past many years.
Let’s dive right into the blog for more insights:
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.
Don't forget to check out: Understanding Salesforce Permissions
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.
Check out another amazing blog by Appheinz here: No Code Salesforce and JotForm Integration | Salesforce Guide
Resource: https://admin.salesforce.com/blog/2023/permissions-updates-learn-moar-spring-23
Responses