Author: Peggy Schael | Salesforce Trainer | WeLearnSalesforce
How Salesforce User Profiles and Permission Sets Fit in With The Data Security Model
Salesforce’s data security model essentially consists of four layers:
The first layer determines a user’s access to the Salesforce organization, like their username and password.
The second layer determines what users can see and do in Salesforce such as viewing specific types of records (a.k.a. Objects), edit or delete records.
The third layer specifies whose records users can access. Not only records they own or created, but also records of their colleagues.
And the fourth layer is all about the level of detail (=fields). How much information should a user be able to see. For example, should a sales user be able to see credit card information? Possibly not! But the finance department may need to.
You guessed it! User permission management therefore belongs to the second layer of the data security model, even before you determine whose records or what fields they get access to.
Types of Salesforce User Permissions – What Users Can SEE and DO
As mentioned earlier, the second layer determines what users can see and do in Salesforce.
What users can ‘see’ relates to settings which specify which Apps users will have access to from the App Launcher and which tabs will be available in the navigation bar. Even if you give Users access to the Sales App for example, you can still restrict access to the Opportunities tab if they wouldn’t require access to this particular tab.
You can also specify what types of records users can see. For example, Accounts may be differentiated by Customer Accounts vs Partner Accounts. Some users may only need to see one or the other.
Plus, the ‘see’ permissions also determine how pages and fields will be displayed to users. You can arrange the order of the information, group them, highlight important details etc.
What users can ‘do’ with what they can ‘see’, is all about what they will be able to do within the Apps, Tabs and Pages they have access to.
This includes Standard Object permissions such as creating opportunity records. Or Custom Object permissions such a creating candidate records.
You also have App Permissions available to choose from. These are permissions only relevant to a specific app to fulfil a particular task, for example converting leads as part of the Marketing App.
And then there are System Permissions which are cross-object permissions like creating reports or creating list views and so on. This means, these permissions are relevant for all types of records.
Salesforce Data Security and Access is part of our comprehensive Salesforce Administrator Certification Course. You’ll learn how it all connects to Salesforce Objects, User Setup and more:
Tools To Assign Salesforce User Permissions
Let’s go back to the future first and understand how things used to be done, and are partially still going to be done. Then, we’ll look into to the future to see what Salesforce is going to change and make easier.
The tools available to a System Administrator to manage user permissions are Profiles, Permission Sets and Permission Set Groups. BTW, these are not going to change as such. Phew! 😅
Let’s start with Profiles and how they have been working up until now: Profiles are used to specify a baseline of permissions users require to do their jobs. Hence, an Admin would pick form the types of SEE and DO permissions to determine this baseline. For example, the Admin would include the Read permission on the Accounts Object.
Such a Profile will then be assigned to one or more users within a particular job function or department. This means, a Profile is often assigned to multiple users within the same job function or team.
Here are the Standard Profiles Salesforce provides out-of-the-box. These have been set up with pre-selected permissions to save the Administrator a lot of time ticking a lot of checkboxes. Standard Profiles are not editable but can be cloned to tailor to specific business requirements. This cloning process creates a so-called Custom Profile, which is simply another version of the Standard Profile.
Permission Sets are an extension to Profiles, to grant additional permissions for specific job functions, for example the Create Accounts permission.
Some organizations are very restrictive about account creations and thus only allow a small number of users, if not only one, to create them. Hence, this type of permission would not be added to a Profile, but to a Permission Set instead.
Therefore, Permission Sets usually contain only 2-3 permissions and are only created as needed and assigned to individual users at a time.
This means, the Admin can pick from the same pool of SEE and DO permissions but selects only what is not already available to the User through their assigned Profile.
The Profile and Permission Set(s) assigned to an individual user essentially determine their total access.
Permission Set Groups were introduced by Salesforce only a few releases ago, and are used to bundle multiple Permission Sets and assign to selected users. This means, that Administrators no longer have to painstakingly assign Permissions Sets one by one. They can now bundle them into a Permission Set Group and assign the entire group of Permission Sets in one go.
Here’s an example of two types of Users within the same department. You can see that some Permission Sets are the same for both, but then there’s one Permission Set which is only required by the Sales Manager. Therefore, we created two Permission Set Groups based on each user’s job function, added the required Permission Sets (which had been created beforehand) and then assigned to each User as appropriate.
Permission Set Groups can be assigned to multiple users, and that’s exactly why they are so handy. Especially in larger organizations where you may have something like five Sales Managers and 20 Sales Assistants or 20 Sales Representatives, you’ll be saving yourself a lot of time when allocating user permissions.
In summary, up until now you would have done the following:
- Set up a Custom Profile containing the minimum permissions, like Read and Edit Accounts (Alert: This part is changing!)
- Create Permission Sets by job function – Remember: DON’T add too many permissions into one Permission Set. It’ll be almost impossible to tell what you have added
- When you realize you have too many Permission Sets to assign to certain users, you’ll create a Permission Set Group to bundle them and make your life a lot easier
Complexity of Salesforce User Profiles and Permission Sets
What happened so far was that System Administrators created a lot of Custom Profiles to allocate business specific permissions. Then they created a lot of Permission Sets for all those additional permissions of each job function. And then they also started creating a lot of Permission Set Groups. 🤯🤯🤯
There’s suddenly A LOT OF everything!
What does this mean? If you don’t have a smart document that tells you which Profile and which Permission Set does what and which user has what assigned, you’ll be running far far away. 🏃♂️
Yes, you can create reports or export a file with Dataloader, but it’ll still be rather difficult to put it all together.
What Will Happen To Salesforce User Profiles
To reduce the amount of Profiles and to add more flexibility to the way you assign or remove user permissions, Salesforce is planning the following changes starting Spring ’26:
👉 Removing most (but not all) user permissions from User Profiles.
IN LIEU, you will need to use Permission Sets and Permission Set Groups, like you already have. But in the future, you’ll manage MOST user permissions through Permission Sets.
Here’s what they will remove from Profiles and ONLY make available through Permission Sets:
👉 ESSENTIALLY, the concept of using Profiles, Permission Sets and Permission Set Groups doesn’t change. Certain permissions like access to Apps, Record Type and Page Layouts will still be managed via Profiles.
BUT, the types of permissions managed through Profiles changes so much so that you will no longer have to create so many Custom Profiles.
Don’t wait for Spring ’26! Start your New BEST PRACTICE already:
Starting a new best practice already will save you time later moving permissions from Profiles to Permission Sets. Here is what this may look like:
- Clone the ‘Minimum Access’ Profile and only use to assign Apps, Record Types and Page Layouts for a particular group of users, like Sales Users or Marketing Users. Nothing else!
- Name the cloned profile after the role or job function, use a meaningful naming convention
- Create Permission Sets by job function – Remember: DON’T add too many permissions into ONE Permission Set. It’ll be almost impossible to tell what you have added. Rather have more Permission Sets with a very precise description
- Bundle job function related Permission Sets into a Permission Set Group, give it a meaningful name, and assign to relevant users
FINAL STEP, if not even the first, DOCUMENT what you set up!!! It doesn’t have to be a fancy schmancy paid document service, it can be a simple as a Word document to get you started. BUT PLEASE, write it down.
Our Salesforce Administrator Certification Course takes you through the setup steps and best practices in a logical order. You’ll be a pro in no time!
How Salesforce Will Help You With The Transition
Salesforce is making a plan to help you make the move from User Profiles to Permission Sets. Here is what they have announced so far. As always, refer to the Release Notes for any further updates on these:
Spring ’23 – Salesforce is introducing the ‘User Access Policies’ feature. It will help you ‘migrate’ user permissions based on specific criteria and attributes. HOWEVER, it will be in Beta and only available to orgs with Enterprise and Unlimited Editions (for now).
Summer ’23 – Field Level Security can be switched to Permission Sets. This is ALREADY in BETA. And is planned to become GA (generally available) in Summer ’23. BEWARE: You must have all your Permission Sets sorted and assigned to Users BEFORE you switch this over. Otherwise, it may get ugly…
Spring ’24 – Turn off ability to assign retiring (EOL = end of life) permissions on User Profiles.
Even though Spring ’26 may seem far away, it’ll arrive sooner than you’d like. And then suddenly, you have to migrate hundreds of user profiles.
Start with the New Best Practice mentioned earlier. For example, if there is any new Custom Profile you have been asked to create, don’t create it right away. See if the New Best Practice may actually be a valid alternative already.
Start making a plan for all your Profiles already on how to move the EOL permissions from User Profiles to Permission Sets and Permission Set Groups. Take it step by step, like department by department or job function by job function.
I hope you found this walk-through helpful. Got a question? Please do leave me a comment below! 👏🏻
WHAT ELSE…
We make learning simple with our range of well-structured Salesforce Video Tutorials, downloadable Study Workbooksand realistic Practice Exams.
And if you are brand new to the world of Salesforce, make sure to sign up to our FREE 21-Day Salesforce Beginners Challenge.
