This tool is for reducing the size of your Profiles by extracting common elements and placing in a common Permission Set.
Complex Salesforce orgs often have large Profiles, and Users can only have one Profile. This means that when you create a new App or implement a Release Update (for example), then your Admins will need to go through and ensure all Profiles are updated the same way. You will then also have to test each Profile fully.
I created a simple command line utility to identify the most common elements in a set of Salesforce Profiles and generate a common subset Permission Set as well as the newly reduced Profiles.
https://github.com/andrewwhitten/Salesforce-Profile-Refactor
Salesforce provides Permission Sets and Permission Set Groups that allow you to define a set of Permissions not tied to any Profile. This means for example that if you have 100 class accesses that are needed by multiple Profiles, you could define one Permission Set and assign to everyone who has those Profiles.
In a really simple example, I cloned three new Profiles from the standard ‘Minimum Access – Salesforce’ Profile. (In a real world example this hierarchy would be better defined as Roles). Each has Profile level access to different Apex Classes in our Org:
We can see that all these Profiles have access to the X-Wing and Y-Wing classes, so we can add those to a Permission Set:
Furthermore, we can see that the ‘General’ and ‘Major’ profiles have other common classes, meaning we can divide up further:
Now, the Rebel Alliance has just acquired a new B-Wing vehicle for everyone. To grant access the Admin can now just add this to the main Permission Set, instead of to each Profile:
For such a simple example it is easy for an Admin to set this up by hand, however what if you have 15 profiles that are thousands of configuration lines long?
The tool generates a Permission Set, however if your common files are still large then I would suggest looking at creating a Permission Set Group and splitting the generated Permission Sets up inside it instead.
Assumptions
This post will only cover the generation of Profile and Permission Set metadata files. The process for pulling and pushing Profile metadata from an org really depends on how well your devops is set up. SFDX tools can pull and deploy Profiles, but not consistently without some issues.
Warning and Disclaimer
Always use this tool in sandboxes and never directly in Production! Try and design an improved Permission Set and Profile combination in a sandbox, and then test that extensively. You need to have personal confidence that the new Permission Set is going to work for your users.
If you do progress to Production, then also do have a roll back strategy to the old Profiles.
Finally, please ensure that you have all the training and knowledge required to pass the ‘Sharing & Visibility Designer’ Certification. You really need to understand how Profiles and Permission Sets work, and all potential impacts to your org. Unit Tests, manual testing and automated testing are rarely comprehensive enough to catch every scenario.
Instructions
- Ensure Microsoft .Net 5.0 is installed on your system (Windows, Mac or Linux)
- Place all Profile metadata files in the \input directory (you can specify another directory for input and output if desired)
- Run this command (sample input files provided): dotnet SalesforceProfileRefactor.dll \input \output
MacOS Example:
You will see a new folder generated under ‘Output’ with the current date and time stamp. Inside is the common Permission Set as well as the newly reduced Profiles:
Open the generated Report.csv in Excel (or similar), and you will see that it has moved 2 Apex Class access elements and 5 user Permission elements into the common Permission Set:
Changing the code:
The tool has been developed in Microsoft .Net 5.0 and should run on Windows, MacOS and Linux. You can change the code in community (free) versions of Microsoft Visual Studio 2019 for either Mac or Windows.
Notes:
- I chose to do this in C# .Net because I already knew how to manipulate XML with it. Additionally Visual Studio is great at generating the XML schema wrapper class.
- At this early stage I doubt there are many people who need this utility. Even I am hoping to use it very rarely. Java would have been a more natural choice for the Salesforce community, but would have taken me longer.
- Code Optimization – I traded accuracy and reliability over code speed. I have a recent i7 running at 2.8 Ghz and the whole operation takes less than 7 seconds to process 600,000 Profile configuration lines, therefore I am not too concerned about it.
- GUI – I have some thoughts about extending this with a user interface to help visualize the process better, perhaps by comparing specific types of elements and attributes between files rather than all.
- Naming – Ensure that the name of the files is correct for either Sfdx or older metadata deployments. I might include this as a command line option in future.
Salesforce & MuleSoft Blog 