A Shift in paradigm - Salesforce Profiles & Permission Sets.

Before we jump into the hot topic of what's the big deal going around Salesforce Profile & Permission Sets, let's revisit few things.

10+ years ago, I started my IT career with Salesforce as a core & within a matter of day learnt that the “Profiles” are mandatory boat to sail through the basics of Salesforce and we can't skip it. The reason underlying is, in Salesforce, users cannot be created without associating a Profile.

Profiles define how users access objects and data, and what they can do within the application & till date, scope of profile is very impactful.

While people were still busy with fixing profiles, roles, OWDs, sharing settings etc., Salesforce in the later stage provided another feature to join the league - Permission Sets. These were added as an extension to Profiles and addressed issues such as:

·??????Assign cluster of permissions & settings to one or specific sets of users.

·??????Assign multiple permission sets to a user without changing profile.

Ok fine, why are we discussing about it again?

The very reason is an official announcement from Salesforce:

Sorry, what do you mean? Wait! Get it Right, before you think too much:

Oh! is it? That means we need to reshuffle the entire security model concept as well as the current state of implementation in Salesforce orgs. Obviously, yes.

To understand more, this change was inevitable & was going to happen sooner or later. This is because of the reason - so many things controlling & manipulating org’s security model. With the simplification and transfer of power, now you wouldn’t need so many profiles. The load of permissions will be sliced off from profiles & taken up by Permission sets.

What will remain on a profile:

1.??????One-to-one relationships—login hours/IP ranges

2.??????Defaults—record types, apps

3.??????Page layout assignment—The future is App Builder/Dynamic Forms so we will not invest in bringing page layout assignment to permission sets.

What will be available only on permission sets after EOL:

1.??????User permissions (system and app permissions)

2.??????Object permissions (object Create, Read, Update, and Delete [CRUD])

3.??????Field permissions (field-level security [FLS])

4.??????Tabs

5.??????Record types (not defaults)

6.??????Apps (not defaults)

7.??????Connected app access

8.??????Apex classes

9.??????Visualforce pages

10.?? Custom permissions

You can further get official details about these changes here.

Overall, the above upcoming changes can be summed up & depicted as below picture - it’s a shift of power & usage:

What Now?

This means as a Salesforce admin, developer, consultant, architects etc. you must start thinking differently, prepare for the future implementation with a focus on these two areas:

1.??????What to do with the current org structure? This will be an uphill task, but it is a change that will make things simpler and should be started as soon as possible.

2.??????What to do with the new orgs and projects? Start with a new approach without a delay.

But NO Worries, Salesforce provides you with couple of tools to resolve it.

Technical jargons you must go through:

1.??????User Access Policies

It is a kind of automation feature & it allows you as a Salesforce Admin to configure policies that allow you to affect entitlement changes for a one-time migration or automatically trigger during user creation or user update.

As of now, there is an agreement link: User Access Policies: Expression of Interest for Closed Beta

2.??????Apart from User Access Policies, you will also need to learn about Permission set groups.

Before creating these groups, first evaluate the types of job functions that your target group of users have, and then, group the permission sets based on their job functions using Permission set groups.

You can follow below steps and add Permission sets to Permission set groups.

3. You can also go to settings -> setup -> User Management Settings -> Field Level Security for Permissions Sets during Field Creation (Beta).

Video demo# 1: Option to enable - Field Level Security for Permissions Sets during Field Creation (Beta).

Video demo# 2: Before and After Scenario: Field Level Security for Permissions Sets during Field Creation (Beta). Don’t miss this.

Thank you & happy reading!