Compare Permissions
Easily compare Profiles, Permission Sets, and whole Users natively in your org. See a color-coded line by line comparison of how they are alike and different.
Background
Architecting and managing permissions can be one of the most challenging aspects of managing a Salesforce org. In a nutshell, these permissions decide what a User can and cannot do in the Salesforce org.
Complicating matters, there are many ways to grant permissions in Salesforce.
As of the time of this writing, a user can get a permission in at least 3 ways:
1 ) The permission is contained in the User’s assigned Profile (each user is assigned only 1 Profile)
2) The permission is contained in any of the User’s assigned Permission Sets (there can be many)
3) The permission is contained in any of the User’s assigned Permission Set Groups (there can be many)
It should be noted that it’s absolutely mission critical that these changes are made accurately, lest a user be given a sensitive permission and see data they are not supposed to see (ex. another user’s sales opportunities), or be given permission to do something they should not be able to do (ex. Export all data).
The problem
As a Salesforce org changes (think: users are added/removed, additional business units are brought on board, etc…), the permissions architecture needs to be updated often.
Truthfully, this is not a one time thing, rather it’s a continuous process, just as changes in the business using the Salesforce org are continuous. In addition to large structural changes, daily minor changes in a business need to be reflected in the Salesforce permissions architecture as well (think: a user needs to be able to edit a certain field, or a business unit should be able to see all accounts).
As you can imagine, based on how many different ways a user can get a certain permission, it is difficult and time consuming (and involves security risk) for Salesforce administrators to make these updates to the permissions architecture. It is not uncommon for admins to spend a full day trying to understand how to grant (or take away) a certain permission from a user. Not to mention, even after this work, the admin may not have the peace of mind that it was done accurately and without granting any extra permissions.
Put simply, without oAtlas, the admin must track down how each permission is granted and attempt to grant or remove permissions without affecting other areas of the system. All while trying to move quickly and accurately. Not an easy task.
How oAtlas can help
Here is where oAtlas is an invaluable tool for managing your Salesforce Permissions Architecture.
Under the “Compare Permissions” tab in oAtlas, you can instantly get a line by line breakdown of every permission inside each Profile, Permission Set, Permission Set Group, and even whole Users (and all permissions assigned to them).
This allows you to very quickly understand how each is built in the org and exactly what they are granting access to.
See the SCREENSHOTS below to see it In Action.
Use Cases
As mentioned above, in any business utilizing Salesforce, it is a continuous process to keep the org’s permission architecture in line and up to date. In addition, there are daily tasks that admins must spend a lot of time on such as figuring out why a certain user cannot access a record or edit a certain field. oAtlas can help in all of these situations.
Here a few example use cases:
1 ) Comparing User access
2) Comparing Profiles
3) Comparing Permission Sets
4) Consolidating Profiles
5) Consolidating Permission Sets
6) Moving from Profiles to Permissions Sets
7) Moving from Permission Sets to Permission Set Groups
8)Troubleshooting User access issues
9) Cleaning up technical debt
10) Permissions Audit
The Result
The oAtlas “Compare Permissions” feature allows you to save time and reduce risk.
It takes a day’s worth of work to solve “why can’t this user edit this field”, down to just a few seconds. It can also allow your org to clean up technical debt in consolidating Profiles & Permission Sets, ultimately leading to a healthier org overall.
Lastly, this leads to risk reduction. As mentioned, without oAtlas, it can be easy for admins to grant too much access inadvertently. For example, in an effort to grant access to an object, the admin may simply clone a Profile and assign that to the user. The problem here is that the cloned Profile may contain many additional permissions that were not supposed to be granted.
With oAtlas, you’ll always know exactly what permissions are inside each structure and what a particular User is able to do in the org, allowing you to seamlessly and confidently make updates to your org’s permissions architecture.