In Automation, Blog, Flow, Security, Tips & Tricks

Power of Custom Permissions in Process Builder

A couple of years ago, I wrote a blog about Custom Permissions in Validation and Workflow rules. Today, it’s one of the most popular and frequented blog posts.

The times have change though. Workflow rules are slowly fading into the past and Process Builder is the new tool of choice for many admins doing declarative automation.

Frustratingly, Custom Permissions weren’t available in Salesforce. This got added a while ago, but it’s a feature that is often overlook and not easily visible to many users.

Why Use Custom Permissions

Custom Permissions gives you a easy way to add or remove people without having to modify your Process Builder.  For example, there can be circumstances where you only want some automation to occur for certain users. You may also want to NOT have automation run for certain users.

I find the latter use case the most interesting with Process Builder. One of the differences with Process Builder from Workflow Rules is how Salesforce “bulkified” the automation. Bulkification refers to how Salesforce handles the automation when multiple records are being created/updated at once. The most common situation is when you’re importing using Data Loader or similar tool.

The consequence is many admins find they can suddenly no longer import records because it causing limits to exceed. This can help when orgs have many Processes being fired at once, often resulting in more processes from being called. For example, I create an Account, updates all opportunities for that account. That calls Opportunities processes which could then also edit/create more records which result in more processes from being called.

It can get complicated pretty quickly. There are better way to solve this problem, but sometimes as Admins, we just don’t have the time to put the long-term fix in right away.

Enter Custom Permissions. You can Create a custom permission and add that as a criteria to all your processes. Then, when you’re going to do an import that would normally break, you simply give yourself the permission and bam! The automation won’t fire and thus your import succeeds.

Why not just deactivate the process? Deactivating the process will turn off the automation to everyone, not just the person who’s doing the import. This means important actions that absolutely should happen, simply won’t happen.  You may also be dealing with lots of different processes that you would need to deactivate. Using a Custom Permission instead is: Easier, Faster, Safer, and let’s face it just darn cool.

Let’s look at how to use Custom Permissions in Process Builder.

How to Use Custom Permissions with Process Builder

First, you need to create the Custom Permission, a Permission Set, and add that Custom Permission to the Permission set. I walk through how to do that in my earlier post: Custom Permissions: The Joy of Flexibility in Validation Rules and Workflow

Second, we need to create a process and for our criteria, select the Formula option.

Yes, you have to use the formula option in order to use Custom Permission with Process Builder. It’s not ideal, but it does work.

Next, you are going to select the third Lookup for the formula: System Vairable

Notice there’s a number of things you can select here. From User Role and Profile down to “Permission.” Clicking on Permission will display a list of All CustomPermissions you have created. Select the one you want and click Choose

You’ll see the custom permission listed in the formula area. You could just type this out, but I always end up missing a weird character when I try it. It’s really easy to go through the UI to select the Custom Permission.

When the Process is evaluated, the reference to the Custom Permission will give you “TRUE” if the running user has the Permission and “FALSE” if it doesn’t.

So adding “=False” to our formula will result in the actions for this criteria node will only run when users do NOT have the custom permission.

Finish adding whatever criteria and viola! You can effectively turn off all the automation for specific users without deactivating and turning it off for everyone.

It’s that simple.

Do you have other use cases for using Custom Permissions with Process Builder? Let me know in the comments!

Don’t miss a post! Sign up to receive email notifications on new posts

Subscribe

Subscribe to our mailing list

* indicates required
I want to receive email notifications about:

Help keep the site running

I run this site, the podcast, and my training videos for the community. I do incur some costs. I greatly appreciate if you can help me out by checking out my affiliates and – if you shop amazon – start your search on my site.

Recommended Posts
Showing 3 comments
  • Christopher
    Reply

    Hi Brian, I need to solve if a Lead record owner is in a set of specific users, then check a box field. It may seem that I’m over-thinking this but I tried accessing a public group in PBuilder with little success.

    So I’ve created a custom permission/perm set/assignment similar to your article. It works if the running user has the custom perm assigned. However, it also need to work when Leads are created with other methods. Example: From the Leads tab CSV Import. If we add the new Lead Owner ID to the import, to get this to work, Marketing will need this custom permission assigned, BUT that means whenever they do an import, it will check the box, even if the import doesn’t need the box checked.

    AND($Permission.RF_Sales_and_Client_Team ,
    OR(ISNEW(), NOT(ISNEW()))
    )

    Maybe it is just not possible to get to the Record Owner’s Custom Permission with Process Builder? How about Flow? I’m hoping not to have to develop Apex code for this.

    Regards,
    Chris

    • Brian Kwong
      Reply

      Custom Permissions are all about if the running user has the permission or not. If you’re basing it off of the Owner, then you’ll need something different.

      Is this a either they are in the group or not? If there aren’t that many users you could hard code (BLEH) in a formula. You could also try using a custom setting or custom metadata. A custom setting would need to be a hierarchy based setting where the global value is “false” (not in group) and then you can add users/profiles underneath where their value is “true” (in the group). I’m pretty sure hierarchy settings are accessible via formula, but worse case scenario you could use a flow.

      Your flow could be even easier since you could just put a custom field on the user record to state if they’re in the group. Or create a public group… or… lots of options. Your flow would then take the owner ID and see if it’s in the public group, or has the field on their user record etc

  • Christopher
    Reply

    Thanks for the speedy reply and great suggestions. I’ll try first the Flow; seems most flexible.
    Cheers,
    Chris

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

User Research ProgramSalesforce Spring 18 WizardCast