At one point I was tasked with reducing a number of profiles in our Salesforce org. I needed to identify profiles that had a small number of differences, delete some of them and fix multiple permissions in the remaining ones.
Comparing profiles with each other especially when it comes to Field Level Security can be boring, time consuming and, to be honest, quite annoying if you don’t have any tools to help you with this process. In addition to this if you are planning a significant number of profile changes, it is better to do them in a sandbox first, test that all your changes are correct and then deploy them to production. But have you ever tried deploying profile changes from a sandbox to production? If yes, then you probably noticed that you have to include all components access to which you changed in profiles into a change set. If this is not done, your changes will not be copied to production correctly. All this increases both amount of work required and a possibility of making a mistake.
That’s when I realized how helpful Force.com IDE can be. Once you bring Profiles metadata into Force.com IDE it allows you to easily see differences between profiles and fix profile permissions. Force.com IDE also simplifies a process of deploying profile changes to a sandbox and then to production.
Let’s look at an example.
I have created a project called Profiles. It includes all metadata components (apart from reports and dashboards). Including all metadata components allows me to fix any Profile permission. If I were only interested in field level security, for example, it would be enough to include just ‘profiles’ and ‘objects’ component types.
I can see three profiles that might be very similar to each other: ‘Sales User – APAC’, ‘Sales User – EMEA’ and ‘Sales User – NASA’. I need to compare them, if the differences are not significant, delete two of them and fix permissions in the remaining one. Depending on the number and type of these differences I may want to move some of them into permission sets (which can also be done using Force.com IDE to save time).
Highlight both ‘Sales User – APAC’ and ‘Sales User – EMEA’ Profiles -> right click and select Compare With -> Each Other.
Both profiles will open with differences being highlighted.
You can use Next Difference and Previous Difference arrows to review profile differences.
My comparison shows that there is only a small number of differences between ‘Sales User – APAC’ and ‘Sales User – EMEA’ profiles. When I repeat the process for ‘Sales User – EMEA’ and ‘Sales User – NASA’, I can see that there are not many differences between them either. As a result I can keep a ‘Sales User – NASA’ profile and delete remaining two.
Fix Profile Permissions
Due to data security reasons I also want to make sure that users with ‘Sales User – NASA’ profile cannot export Salesforce reports. Right now they have this permission.
To change profile permissions double-click a Profile name to open an .xml file with its metadata.
Opened file contains information about ‘Sales User – NASA’ profile permissions.
Use CTRL + F to find ‘ExportReport’ permission. As you can see, this permission is currently set to True.
Change ‘true’ to ‘false’ and click CTRL + S to save your changes locally on your PC.
Then right click a Profile name -> Force.com -> Save to Server.
Once the operation is completed open a profile in Salesforce to see the changes.
If your project is linked to a sandbox and not to production, you still need to copy changes to production once the testing is completed. To do it click on the name of the profile (or on ‘profiles’ folder to save all changes in one go) -> select Force.com -> Deploy to Server -> enter username, password and security token (if exists) for your production org and follow the completion steps.
Now your changes have been saved into both a sandbox and production.
Important! Always check the Problems tab (if there are any issues with your files, no changes will be saved to Salesforce) and spot check metadata you are changing in Salesforce.