Clean Up Profiles and Permission Sets in Salesforce
Profiles and Permission Sets work together to determine which objects users can access and what actions they can perform inside Salesforce. These features are critical to Salesforce security but overtime, it can be easy to end up with too many Profiles and Permission Sets, including some that are no longer relevant.
In this article, we’ll explore the ways you can clean up Profiles and Permission Sets, improving your org health.
Why is this a Problem?
For the purposes of this guide, I’ll be assuming you understand the difference between a Profile and a Permission Set. If you’d like, you can refer to this excellent breakdown by Lucy here.
If we were to compare a Salesforce org to a house, Profiles and Permission Sets (“PermSets”) might be the floors. OK, it’s not a perfect analogy, but the point is that Profiles and PermSets operate in the background of the org, but they touch nearly everything, much like the floors of a house.
If you bring anything into the house, it’s most likely going to make contact with the floor and interact with it in some way. In much the same way, nearly every action you take in Salesforce (and anything new you bring in) as an admin will touch Profiles and PermSets (a new Field, a new Record Type, a new App install, or creating a new User for example).
After even a small amount of customization in your org, Profiles and PermSets begin to be embedded deep in the system. And since they are so integrated in the org, I would argue that as goes the cleanliness of these, so goes the cleanliness and organization of your overall org (ie. your “Org Health”). This is why it’s so critical to have clean and organized Profiles and PermSets. In fact, when I come into a new org and am tasked with improving “Org Health,” this is the first place I start.
Step 1: Delete Unused Profiles and PermSets
The first and easiest step in cleaning up Profiles and PermSets in your org is to identify which are simply not being used. These are Profiles and PermSets that have no active users assigned to them. At the same time, let’s get an overall picture of how many Users are assigned to each Profile.
Within each Profile and PermSet you can view the assigned users and sort by the “Active” column (Profiles > Assigned Users OR Permission Sets > Manage Assignments), but this very quickly becomes impractical when we are talking about doing this across hundreds of Profiles / PermSets. Luckily, Salesforce has some (limited) reporting capabilities on the org itself, and Users (with their Profile assigned) is one area we can report on.
Create a User report
Start by creating a new report on “Users.” It should pull in the fields we need automatically, but if not we’ll need (First Name, Last Name, Username, Active, Last Login). Let’s add “Profile” as a grouping, change the Filters for “View” to “All Users” (instead of just active users) and refresh the report. You should now see the number of overall users assigned to each Profile.
Now, what we are trying to do is see how many active users are assigned each Profile, and determine if there are any with no active users or maybe just 1 or 2 users. In order to do this, we’ll need to create a “Summary Formula” in the columns. If you click the down arrow next to “Columns” on the left, you should see “Add Summary Formula”, click to add. Call the summary “Number of Active Users” and on the left search for the “Active” field, highlight it, and click the “Insert” button. Your formula should say “ACTIVE:SUM”, change the “Decimal Points” to zero, click “Apply” and refresh the report.
When you run the report you should now see the number of active users per Profile!
Let’s pause here and ask “what do you see?”
Highlight Unused Profiles
This is our first opportunity to do some cleaning. If you see any Profile groupings with zero Active users (or only 1 active user), these are low hanging fruit and should be placed under consideration for deletion from the org.
Before actually deleting the Profiles from the org, we should do a couple of things. First, I would recommend creating a Google Doc (or some other document) to keep track of the Profiles under consideration for removal. Back in the org, I would view each Profile and try to understand why they were created, by whom, and what the reason might have been. If the admin who originally created the Profile is still around, it might be a good idea to ask them these questions and gather the details in the aforementioned document.
It’s also possible to use your best judgement, especially if the admin(s) who created these are long gone. If you see a Profile with no Active Users and it was created five years ago, it is most likely safe to remove. On the other hand, if you see a Profile with no Active Users and it was created just a few months ago, you probably want to check with whoever created it and ask if it might still be in use / waiting to be used for some special purpose.
Remove Assigned Users
After this judgement and investigative work, you should have a definitive list of Profiles you are prepared to delete from the org. The last hurdle is that you cannot delete a Profile that has Users assigned to it (even if all the users assigned are inactive) and every User must be assigned to a Profile. What to do?
I would recommend creating an “Inactive Profile” to hold all these Users that need to be reassigned (and any future ones). I usually name the Profile “Z – DO NOT USE – INACTIVE PROFILE” (the “Z” ensures it will be last in the profile list view). Now you’ll need to go through each Profile marked for deletion, view the Assigned Users, and one by one re-assign these Users to the new “Inactive Profile” we just created. Once each of the Users are re-assigned, we are finally ready to delete the Profile.
Click the “Delete” Button and Confirm!
Let’s pause when all the Profiles marked for removal have been deleted.
Do a happy dance and pat yourself on the back, you just greatly improved your Org Health!
But wait, that was Profiles, what about Permission Sets?
Repeating the Process for Permission Sets
Unfortunately there is no way to report on Permission Sets (and the number of Active / Total Users) in Salesforce the way we just did with Profiles. What I would recommend doing is going into the list view of all Permission Sets in your org, and copying (click and drag) the name and description of all in the org. You can then paste this list into Excel/Google sheets and with some light cleaning, get a solid list of all the PermSets in your org.
Then, go into each one in Salesforce, click “View Assignments”, and sort by the Active column. Count up the number of “Active Users” assigned for each Profile and mark that down in the document you just created.
Note: You can run “Salesforce Optimizer” which will give you a list of “Unassigned Permission Sets” specifically for this step of identifying “Active Users” but this list will not show the total number of users and the breakdown between active vs. inactive total users that are assigned to each the way we did with Profiles above. Optimizer also does not count “Inactive Users” as assignments, so even for this list of “Unassigned Permission Sets,” some users may still be assigned. As we saw above with Profiles, these Permission Sets would then not be able to be deleted since even inactive assignments would need to be removed before deletion.
After a bit of manual work, and then the investigative work, you should arrive at the same point as we did with Profiles, with a solid list of Permission Sets marked for deletion.
Step 2: Proper Naming Conventions
Now that we have removed unused Profiles and PermSets, we should better organize the remaining ones we intend to keep using. One of the easiest ways to prevent Profiles and PermSets from getting being unncessarily created (either by you or a fellow admin) is to have each of them properly named. This will ensure it’s clear what’s in each and what job function it’s for (it will also help us in Step 3).
But, how do we know what’s in each profile and what job function it’s for?
Examine What’s Inside Each Profile
What would be great is to see all of the permissions inside each, spilled out in one easy list; unfortunately an easy way to get this is not available in Salesforce. So, this is going to take some investigative work.
Similar to the Google doc we created in Step 1, I would recommend creating another one just to store our notes on what is actually inside each Profile / PermSet. For this task, I would expect to get information from Setup (via directly looking inside each Profile / PermSet) and also from other admins (assuming there are other admins at your company).
First, see what you can gather from the existing name and the description field. If you are lucky, there may be some information there to begin to get an idea of what each Profile does. You can also take a look at what Users are currently assigned to this Profile, their Role name or other information which may start to give you an idea of what the Profile is being used for.
Next, for the information from Setup, start by just doing some poking around. When viewing each Profile, depending on how your “User Management” settings are configured, you should be able to get a high level overview of what permissions are in each Profile. You should see which Objects are granted access to, system permissions, and others. Unfortunately, for finer details like Field Access, you’ll need to click into each and every Object to view that. But, the main idea here is to get a rough idea of what’s in the Profile, so we aren’t looking for every possible permission within it.
For the human information gathered, similar to Step 1, I would ask the other Admins who created some of these Profiles: why was this created, what users were in mind when it was created, and what were the circumstances surrounding it’s creation (ie. a special project, special permission needed, a new type of user coming into the org, etc)?
With some patience and using the investigative methods above, you should arrive at a decent idea of what each Profile does.
There are many ways to go about this, but what I would recommend is using a naming scheme like: “JOB FUNCTION – More Specific Term(s)”. Examples: “SALES USER – Management”, “SALES USER – Outside Sales”, “MARKETING USER – Regular”, “MARKETING USER – Power User”.
Click “Edit Properties” and update the name of each Profile.
Repeat for Permission Sets
You should repeat the above process for Permission Sets. Unfortunately, Permission Sets do not have a “view all permissions inside” kind of view that Profiles have, so you’ll have to rely more on poking around within each permission category, discussing with other Admins, and hoping that the existing name or description can help you determine what’s inside.
Step 3: Combine Similar Profiles and Convert Profiles to Permission Sets
With the unused Profiles and PermSets removed from the org, and all of them properly named, we are finally in a great place to begin consolidating what’s left.
Based on Step 2, you should already have an idea of which Profiles might be similar. “SALES – Regular User” vs. “SALES – Regional User” might be a good candidate for examination.
What would be great is to see all of the permissions inside, compared against another Profile and all of the permissions inside that one. Luckily, a Salesforce employee built a free tool to do just that called “PermComparator”.
With the PermCompator tool, you login with your org credentials and are shown a drag and drop interface where you can drag a Profile into one of the boxes and ‘compare’ it against another Profile. You then see which permissions they have in common and which are different.
**I do want to highlight one very important caveat. This tool does not provide every possible permission that is contained in a Profile or PermSet. It has many including Object access, System Permissions (like convert leads, view setup, etc), and App access, but is missing permissions for Fields, Record Types, and others. So, this tool should be a very good guide, but not a perfect solution for comparing profiles.
Armed with this new knowledge, you should begin to see which Profiles are good candidates for consolidation. Usually, the most likely candidates will be Profiles with near-exact permissions inside but one has a few extra system permissions (e.g. Manage List Views and Export Reports). For cases like this, the Profiles should be combined and a Permission Set should be created for each special permission.
Working from the example above, we would need to create two new Permission Sets. Let’s call them “REPORTS – Export Reports” and “LIST VIEWS – Manage List Views” and assign whichever Users need these permissions to each of these new PermSets. Then, go into the Profile we intend to delete, view all assigned users, and move all of them over to the other similar Profile. You should now be able to delete the Profile that has no users assigned to it, just as we did in Step 1.
Repeat for Permission Sets
You should repeat the above process for Permission Sets to determine if any could be combined/deleted.
Prepare for User Issues
We have taken every precaution to not cause any issues for the Users involved in these changes, but without fail, a field permission or some other small thing will be missed. I would recommend staying vigilant during the first few days after making these changes to Profiles and PermSets. This will allow you to quickly resolve any issues, restore small permissions that you missed, and ensure there are no major disruptions in the day to day operations of the system.
**While undergoing all of this, I would be especially careful of any Integrations. If you know that some Users are assigned to an Integration Profile, I would tread very lightly on that one as changing permissions that an Integration User has could break a big job that runs or custom code that is being used in the background.
Think About the Future
After this 3 step process, your org should be left with a clean list of Profiles and Permission Sets.
Congratulations on this accomplishment, it will pay dividends for your org for years to come!
But, how do we ensure it stays this way?
Communicate Naming Convention
Anybody who is creating Profiles or PermSets in the org should be made aware of the ‘Naming Convention’ you have adopted. Have a meeting with all of the Admins of your org and communicate this new naming convention. This way, anything new that is created will be sure to have a clean and descriptive name, and it will be immediately clear if the org is beginning to get cluttered again.
Documentation is just putting words down to explain why a part of the org was built a certain way and maybe some information about who requested it. It’s not nearly as complicated as it sounds and should not feel intimidating. However, documentation is incredibly powerful in keeping your org clean, and it’s usually sorely lacking in Salesforce orgs.
Documentation would have saved us a ton of time over the 3 steps above as it would have been clear right from the start why a Profile or PermSet was created, who created it, and under what circumstances it was created.
So, since we have just gone through the difficult task above, and we already have a list of what each Profile is and what’s inside, I would recommend creating some Documentation. It’s really simple. Just create a document (or use one of the ones you already created as a jumping-off point), list each Profile and PermSet and provide some notes on what’s inside, what it’s for, etc.
Now, everytime a Profile or PermSet is created (or updated in a major way), make sure you update the Documentation! This will ensure everyone is on the same page and if you need to do another clean-up project in the future, you can refer to your handy ‘living’ org Documentation!
oAtlas – Understand, Document, and Report on your Salesforce org.
I’ve done the exercise above for more orgs than I can count. This was one of the things that originally led me to dream up a tool to “quickly understand how an org is built and how it’s being used.” Fast forward 5 years and oAtlas was born.
oAtlas alleviates much of the difficult points above, including:
- Instantly see every permission contained in a Profile or PermSet. (no more clicking through endless menus in Setup as we had to do in Step 2).
- Full permissions reporting right in Salesforce via the standard Salesforce reporting engine (easily compare profiles to see their differences, even down to the field level).
- Instantly see how many active / inactive users in each Profile and PermSet (no more manually figuring how many users are in each Permission Set as in Step 1).
- Documentation right in your org.
With Salesforce native Documentation, you can document your org, communicate major changes across your Salesforce team via Chatter, and even run Salesforce projects through an approval process, all right in your org.
Visit the oATLAS website to learn more or email [email protected] to get in touch (we are currently offering a free org analysis). You can also get a free org documentation template here.
Perfect timing on this article as I was just asked by a client to help with this specific situation. Thanks!
In step one – Creating User Report under profiles:
When I drop-down the arrow by “Columns,” the “Add Summary Formula” is grayed out. Anyone know what to do in this situation?
Thank you for reading!
You’ll need to add a “grouping” before being able to create a summary formula.
A summary formula actually sums up these groupings, so you must have one or else there is nothing to create a summary of.
Up above the columns you’ll see “group rows”…click in the “add group” search box and find “Profile”.
Once you add “Profile” as a grouping, when you go back to columns you should now see the add summary formula is available.
Super helpful article! Helped me create a game plan for cleaning up my org. Thanks!
Thanks for reading!
Awesome Chelsea, glad it helped!
If you’d like a trial of oAtlas to take your clean-up into areas like Groups, Roles, etc… let us know!
Great article! We were planning to transition to permission sets but I see some obstacles. Our general idea was to create one basic Profile and assign permission sets. However, we do have some apps that are assigned to specific profiles and as of now SF does not have the option to assign apps to permission sets. Does anyone have an idea of what should be the best approach?
Great article! We were planning to transition to permission sets but I see some obstacles.
Our general idea was to create one basic Profile and assign permission sets.
However, we do have some apps that are assigned to specific profiles and as of now SF does not have the option to assign apps to permission sets.
Does anyone have an idea of what should be the best approach?