Security and access in Salesforce is one of the most important topics in the ecosystem – keeping your data and the integrity of your implementation remain a top priority for all users. Regardless of your level of expertise in the ecosystem, you should be familiar with the principle of least privilege which helps ensure every user has the bespoke access needed to complete their tasks, as well as the Salesforce features that allow you to have this granular control over what users can do and see in the CRM.
In this article, we will explore a few permissions that you should either avoid assigning to users altogether or grant sparingly, as well as the potential and negative impacts the extended access these offerings may have when in the wrong hands.
Standard Permissions
Out-of-the-box, Salesforce offers quite a few readily available permissions that you can add to either Profiles, or preferably, Permission Sets. These standard permissions include everything from System Permissions such as Manage Users or App Permissions like Run Flows. They are presented as checkboxes that you, as a Salesforce Admin, can check to grant access to different functionalities across the platform.
Although seemingly harmless from an admin task perspective, these checkboxes can yield significant consequences and lead to unwanted changes in your production environment, resulting in time spent fixing something that could have been prevented from the start.
Depending on what kind of access you are looking forward to granting a group of users, chances are that you will use one or more of these standard permissions to achieve the end result. For example, if we’re looking at the Lead conversion process that Business Development Reps need to perform, the needed access is a mix between Object permissions as well as the Convert Leads App Permission.
On top of the access aspect, standard permissions can also be used in conjunction with other Salesforce features, such as Record Page component filtering, or even prompt filtering for In-App Guidance. While you may not know all of them by heart, (truth be told you will not use absolutely all standard permissions at the same time) knowing what they can be used for even further than their initial purpose is crucial. In the filtering scenarios, why would you create a custom permission if you could just use a standard one if warranted?
Permissions You Should Not Assign to Users
As mentioned above, a mere checkbox set to true when it comes to Salesforce permissions can cause quite a headache. With that being said, let’s look at ten Salesforce permissions that are suitable for Admins, and are ideal for an extremely low number of users (or none at all).
1. Customize Application
In the context of user permissions and tailoring them according to their needs, there are potentially bad decisions, and then there’s Customize Application. This is one of the most powerful administrative permissions in Salesforce, providing (as the name suggests) the ability to customize mostly everything across the instance.
Users who are assigned this system permission are able to manage objects and fields, as well as enable or disable critical functionality. When enabling this permission in a permission set, related permissions are also selected for you to review before saving.
Fixing potential mistakes that may happen due to this permission being assigned to non-admin users may be quite the feat. If you would like to prevent realizing that fields have been deleted in the production org for example by a user, make sure to review who this permission is assigned to and re-consider how it will be granted in the future.
2. Manage Users
Another System Permission that should be assigned to Salesforce Admins only is Manage Users. Similar to Customize Application, this permission doesn’t include access to one single functionality, but to everything that has to do with creating and editing, ensuring users are ready to use Salesforce.
Instead of assigning this permission to users who need to manage a certain team, you should explore the Delegated Administrator functionality first, as it allows you to define which Roles and Subordinates can be managed by delegated admins, without worrying that Profiles, Password Policies, or other features will be impacted.
3. Modify All Data
To complete the trifecta of “dangerous” System Permissions in Salesforce, we have to mention Modify All Data. While it is expected for admins and data stewards to have this permission in a production environment for their day-to-day tasks, granting the ability to create, read, edit, and even delete records across all Objects regardless of sharing settings to a large number of users is not a good idea neither in theory nor in practice.
Even with a backup and recovery solution implemented, potential mistakes may result in time spent on recovering information, which can be better spent elsewhere.
Moreover, if certain power users need to manage all records of one or multiple objects as part of their role, the Modify All Object level permission is a much better option to tailor their access, considering that once Modify All Data is enabled, other permissions are automatically enabled as well – make sure to check the complete list here.
Another use case that may lead to Modify All Data being assigned to users is the ability to log in as another user, a feature generally used for troubleshooting purposes. While assigning this permission would meet the requirement, it would also open up all the additional access mentioned above, as well as the ability to log in as any user – a better alternative in this scenario is once again setting up delegated administrators.
4. View All Data
View All Data grants users read access across all records in your CRM irrespective of the sharing settings, and it goes hand in hand with Modify All Data, in the sense that if it can be avoided (and most times it can), you shouldn’t assign it to users outside out the admin team.
If it’s only view permissions, what can be so bad, right? Considering that different types of personal information, revenue, and transactional data are stored in your Salesforce org, it’s not at all a good idea for more users than needed to see everything if they don’t absolutely need to. In the situations when it is indeed needed for non-admin users to view all Object records, it is recommended once again to make use of the available View All Object permission instead.
This way, you can pick and choose exactly what the user needs, and of course in combination with Field Level Security, obtain the desired access across all of the records.
5. Manage Profiles and Permission Sets
Have you ever spotted a new Permission Set in your production environment and wondered where it came from? Hopefully not, as long as the Manage Profiles and Permission Sets permission remains an admin-only permission, that will not be the case. This permission allows users to create, edit, and delete Profiles, Permission Sets, but also Permission Set Groups.
Since all these are crucial to controlling access for your Salesforce users, there shouldn’t be a reason for other colleagues outside of the Salesforce team to decide when a Profile should be created, edited or deleted for example, as they may now be aware of all considerations and potential implications this change can have.
6. Manage Custom Report Types
The easiest way to ensure that you will need to clean up the Custom Report Types is to assign the Manage Custom Report Type permissions to users and wait! Jokes aside, this permission allows anyone who has it to navigate to Setup and create or edit Custom Report Types and should be reserved for admins and analytics power users only.
The relatively new Details sidebar makes it much easier to see exactly which objects are included in Report Types before choosing it and creating the Report, but chances are that users won’t check this, and simply leverage the name of the Report Type.
In the example below, the Custom Report Type is named Account and Contacts, but in fact, it uses Opportunities which may or may not have Opportunity Contact Roles – quite different, right? On top of this, users may also end up creating duplicates, rather than using the existing ones or just updating the layout.
7. Manage Public List Views
List Views are great, and pack a lot of functionality which users generally enjoy, especially as they are easy to access. The Manage Public List Views permission however should not be treated lightly and granted to everyone, as it enables users who have it to create, edit, delete, and modify sharing settings for List Views across all Objects.
When too many users have this level of access, you could rapidly discover public List Views that users created only for themselves, making it harder for other colleagues to find the ones they actually need to use.
Also, users might change the display columns as well as the filters for existing List Views, making them confusing to keep using. In the example below, the List View is called Today’s Leads, but the Date Filter is yesterday (and most users won’t necessarily check the filters). In short, this permission can turn a great feature into a confusing and unusable one.
As an alternative to extending the access to everyone, you can train users to know that they can create private List Views for their own use and assign them the Create and Customize List Views permission, but if they need public ones available to their team or other colleagues, they should reach out to the Salesforce Admin, or perhaps a power user which has the Manage Public List Views permission and is using it responsibly.
8. Manage Reports in Public Folders
A personal favorite of mine, this permission is bound to cause quite a headache if assigned to more users than needed, especially when you embed one or more Report Chart components on Lightning Pages. Similar to Manage Public List Views, the Manage Reports in Public Folders permission is not on an object-by-object basis. But once assigned it grants access to create, edit, and even delete all Reports in shared folders.
Limiting this permission as much as possible can save a lot of time and troubleshooting effort, especially since within your org there surely are at least a few Reports which are shared with a large number of users or are part of Dashboards. If one of these widely used Reports is also embedded on a Record Page for example, changing the Report may also result in an error or wrong data due to filters for all users, which is not a great user experience.
This permission is just one of the available Reports and Dashboards-related permissions, so make sure to check the other ones as well prior to investigating the assignments.
9. Manage Territories
Sales Territories is a sharing mechanism and an out-of-the-box way to organize your Sales team, Accounts, Opportunities, and even Leads. Records can be related through Territories through assignment rules, and multiple Users can be added to the Territories as well in different roles, to enhance collaboration and ensure record access.
But who is making all these decisions and changes? “Manage Territories” is the permission that allows full control over Sales Territories functionality, meaning that users with this level of access can create Territory Models, archive them, manage individual Territory and the Territory hierarchy, as well as add or remove Users.
Salesforce Admins will of course have this permission, but the nature of the functionality dictates that Revenue or Sales Operations should have this permission in order to properly maintain their areas and allocate Territories to team members. Assigning this permission to Sales Managers or other groups of users may result in mistakes that may or may not be easily reverted, with impact across record access, revenue attribution, reporting, and of course the Sales Territories implementation, if for example, the active Territory Model is archived.
10. Download AppExchange Packages
With a myriad of third-party solutions available on Salesforce’s AppExchange for various use cases, it should come as no surprise that the permission to install one of them in the Salesforce instance has made it on our list. Users may be curious about these products and keen to try them out, and unintentionally proceed with the installation in the production environment.
The Download AppExchange Packages permission should be reserved for admins only, without a shadow of a doubt, as not only does it allow the actual install of the managed package, but once checked, many other App, Object, and System Permissions are enabled – including Customize Application.
Ways to Monitor Assigned Permissions
One of the newer enhancements with User management in Salesforce is the View Summary button available on any User’s page. This is the perfect option to quickly check if a given User has any high-risk permission assigned, which would explain for example how they succeeded in creating a new field or deleting records.
This option is a significant step ahead and reduces the number of clicks needed to go through all Permission Sets assigned to a user and check App Permissions, System Permissions as well as Object Permissions. At this time, however, this view doesn’t share exactly which Permission Set contains the permissions in the list, meaning that a cross-check is still needed after concluding that the User does indeed have a permission which should be removed.
View Summary is also available at the Permission Set level, so you can easily see which User Permissions are enabled in an individual Permission Set, rather than a particular User.
Alternatively, if you are comfortable with using SOQL to retrieve information from Salesforce and would like to have the information across multiple Permission Sets, then you can simply leverage queries to determine which Permission Sets have one of the above standard permissions assigned. This option is much faster than the UI alternative, as it removes the need to click through either Users or Permission Sets and scroll through the enabled permissions and Permission Sets, returning everything to one place.
Below is an example to check the Permission Set Assignments where the related Permission Set includes the Modify All Data permission. You can further customize the query for your particular use case if you’re looking for other permissions and combinations of permissions or if you’d like to review permissions included in Profiles as well.
SELECT Id, PermissionSet.Id, Assignee.Name, PermissionSet.Name
FROM PermissionSetAssignment
WHERE PermissionSet.PermissionsModifyAllData = true AND PermissionSet.IsOwnedByProfile = false
Summary
Each Salesforce implementation is very different, as it is the decision-making process behind which permissions are to be granted or not to the end users outside of the team managing Salesforce.
While your organizations may choose to assign one or more of the above-mentioned permissions to some power users to facilitate different processes, make sure that the pros and cons are considered accordingly to mitigate any potential risk the additional access may bring along.
Since the list in this article doesn’t cover absolutely all possible permissions, we’re curious to know what is one permission you believe shouldn’t ever be assigned to users, and why?
Let us know in the comments section below!