Future of Profiles in Salesforce

Profiles were Everything

If you have been in the Salesforce ecosystem for a decade or so, you know how important Profiles are and how important it is to get them right. Back in the day, any permissions in the system that were not directly related to accessing data (records) were at the Profile level, starting from CRUD access, to System Permissions all the way up to IP restricted logins and everything in between.

That started creating complexity in managing profiles for Salesforce Clients. The no. of profiles in some complex Orgs started to grow exponentially. I have personally seen Orgs that had more than 200 active profiles. Basically if you have a new user personal, that mapped to an existing persona, but with a few tweaks in permissions for their needs, you had no option but to create a brand new Profile.

Introduction of Permission Sets

Salesforce realized what the issue was and introduced Permission Sets. Basically, a delta of permissions that can be assigned to a user without having to create a new profile. This capability kept expanding every release since the initial introduction.

Then came the concept of Permission Set Groups, a way to group Permission Sets under one umbrella and assign the Group instead of assigning individual Permission Sets.

Then we had the Muting Permission Sets that can be added to a permission set group to revoke some permissions that a Permission Set in a Permission Set Group is giving.

There are many use cases for Muting Permission Sets e.g when you want to use a Permission Set in a Permission Set Group but may have to create another Permission Set just because of a small subset of permissions that you cannot give, you may create a Muting Permission Set instead and add it to the Permission Set Group .

But the bottom line is that the new model gives you a lot of flexibility. As an architect you can decide what level of granularity you are looking for in a Permission Set or a Permission Set Gropu. In a typical enterprise you would generally map your Users to Active Directory and your Profiles to AD Groups. Ad GrouPermission Set could map to a lot of things, roles, public groups etc but in this new world they should ideally map to a Permission Set Group and you manage the Salesforce security complexity inside a Permission Set Group so our Identity provider does not have to worry about it.

Are profiles Deprecating?

But why are we talking about this now? Unless you have been living under a rock you already know that Profiles are going to Deprecate, eventually, its a long roadmap so you are safe now but the future is Permission Set Group and Permission Sets. At some point in the future you will have to fully migrate to Permission Sets and Permission Set Groups but if you are in a greenfield implementation now, how can your decisions today save you from a costly migration in the future, let’s talk about that.

Here is the official article about the deprecation plan:

https://admin.salesforce.com/blog/2023/permissions-updates-learn-moar-spring-23

Profiles are not fully deprecated they will still exist but only with these functions

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

Everything else moves over to Permission Sets.

• 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

There is a beta to automate the migration but why even worry about it if you can build the right way ground up in a greenfield implementation.

Here are some best practices on how we make a decision around a profile, permission set and permission set groups.

• Identify your Personas (Note that Persona’s are not profiles)
• Trying to minimize Profiles. Default record types and apps is really the only reason for a separate Profile. (Move to Dynamic forms if you can)
• Layer Permission Sets based on job function.
• Bundle Permission Sets through Permission Set Group, ideally one per Persona.

To double click on Dynamic forms, page layout assignments is really the only big dependency on Profiles. Otherwise everything in the lightning builder is very flexible. You can now go down to the component level to control visibility by user attributes or Custom Permissions. The detail tab comes out of the traditional page layout. Once that is updated to dynamic forms that key dependency ends and it’s easier to imagine a world without Profiles. (Dynamic forms currently support limited standard objects and all custom objects, but the basic Lead, Account, Contact, Opportunity, Case are covered).

Note that profiles are still involved in assigning a lightning record page, but it’s somewhat irrelevant, you can have one version of the page for all profiles, because you are now able to granularly control visibility of everything inside the page.

Here is a sample decision making flowchart you can use when you have a new persona that you are trying to assess. This example assumes you have a set of Profiles, Permission Set and PSG’s and are assessing a new Persona.

In Conclusion

Adapt to Permission Sets and Permission Set Groups and reduce dependency on Profiles. In Parallel, also start adopting dynamic forms. This will help you prevent a potentially costly migration from Profiles to Permission sets and page layouts to Dynamic forms in the future.