Custom Permissions in Salesforce: Fine-Tuning User Access

Salesforce as a platform is great and offers possibilities to customize overall access, permissions, and experience for small or large groups of users. But what happens when we are looking at limiting certain functionalities to individual users, which may or may not represent the same persona or team?

In this post, we will explore how Salesforce Admins can easily set up component visibility and functionality access so that there is no need to even think about hardcoding user IDs or compromising on your current profile setup.

Salesforce Custom Permissions

Don’t you mean permission sets? Not quite. Custom Permissions in Salesforce represent a control mechanism for custom functionality, which is not readily available within permission sets or profiles. However, once the custom permission is created, it can be enabled in a permission set or a profile to allow access to a certain item or process – such as a button on a custom page or limit who can bypass a validation rule.

This means that while custom permissions will most likely be enabled as part of a permission set rather than a profile in an org where only minimum access is granted through the profile already, it is a separate functionality altogether which has to be considered depending on the requirements at hand.

Additionally, you can create dependencies between custom permissions. This way, you can ensure that when the parent permission is enabled, the required custom permissions will be added as well.

Create a Custom Permission in Salesforce

While it may sound like there is more to start making use of custom permissions, it is actually as simple as creating a custom field. It is recommended that you name the custom permissions clearly and add a description in accordance with the process of functionality they are meant to support.

Use Cases for Salesforce Custom Permissions

While you can most likely already imagine processes in your own Salesforce instance that might just be the right fit for using custom permissions, let’s deep dive into a few of the more specific situations which you will encounter if you haven’t already.

1. Validation Rules and Formulas

One of the most popular ways to support data integrity in Salesforce is validation rules. Naturally, there could be exceptions to every rule, right?

As a best practice, hardcoding should be avoided at all costs as it can and most likely will cause issues down the line. Custom permissions are one of the ways to create exceptions within validation rules, alongside custom settings, for example. Long story short, all you have to do is ensure that users who should be exempted from a particular validation rule have those permissions. When this option exists, why even bother thinking about user IDs?

In the simple example below, a field cannot be changed depending on the value of another field, as the permission is not assigned to the current user. Of course, you can choose to tailor your validation rule however you wish, let’s say to allow the field to be edited only if it doesn’t have a value or if the value (in this case for AnnualRevenue) is lower than a certain threshold.

In the same way that custom permissions are referenced in validation rules, they might as well be used in custom formula fields if needed.

2. Lightning Page Filters

In a Salesforce instance that is heavily making use of the various readily available components or the wide variety of custom ones, it becomes a necessity to properly control who sees what in order to avoid cluttered pages that negatively impact the user experience.

For example, let’s say that both the sales and service teams use the same account record page. However, only a very specific subset of the sales users need to view a certain component positioned at the top of the record page. Chances are that the sales users will share the same profile, and even though they might have a different permission set or permission set group, this cannot be used for filtering. This is where custom permissions come in handy!

As the requirements might evolve, nothing is stopping you from using this custom permission across other objects as well – it all depends on what the actual need is. In the eventuality in which the filtered component should be added to accounts, leads, and contacts, you can use the same filter on all the pages to narrow the component visibility.

Even more so, if you have already upgraded to Dynamic Actions, you can also filter each individual action based on the custom permission as well.

3. In-App Guidance

When thinking about user enablement, Salesforce’s In-App Guidance is ideal for building either step-by-step guides in the form of walkthroughs or individual prompts, which can contain a short message and related resources. Once again, while profiles can be used as a filter for the viewer of the pop-ups, permission sets cannot. You will have to use either standard or custom permissions for a more focused audience.

The first step is to actually create the custom permissions – and ideally, it would be one for each individual use case you’re considering. In this example, onboarding is an ongoing scenario as chances are there will continue to be new hires who will have to become familiar with the Salesforce process.

Since the example is focused on inside sales, the walkthrough below sits on the opportunity page, and is meant to guide them through some of the basic information and resources. Once the walkthrough is built and saved, you will be able to input the permissions filter as well.

4. Salesforce Flow

As Salesforce Admins start becoming more and more proficient in using flows since this is THE declarative automation tool nowadays, let’s see how and where custom permissions can easily be used as criteria within Salesforce Flow automations or guided wizards.

While the use of the custom permissions highly depends on what the flow is actually supposed to do, they can be used as part of an entry criteria formula, a formula resource, or even a decision element. The custom permissions can be referenced through the $Permission global variable, which represents the current user’s custom permission access.

5. Apex

Similar to the declarative approaches, custom permissions can also be used in custom Apex code to confirm if a user has a certain permission or not. While for complex implementations involving code you will have to work with a developer, there isn’t any reason why they can’t use the custom permissions you already created as long as they would serve access to different parts of the same process or are tailored for the same audience.

Final Thoughts

All in all, custom permissions open up a whole new realm of possibilities – be it in declarative or programmatic implementations – considering both the process integrity and user experience. They are a feature you have full control over without having to depend on pre-existing permissions for your custom solutions.

Have you already used custom permissions? Share in the comment section below!