Last Updated on February 10, 2022 by Rakesh Gupta
Process Builder is one of the most powerful tools provided by Salesforce to implement business requirements declaratively. Process Builder helps businesses to save time, as well as money, by implementing solutions quickly. Implementation of Process Builder is straightforward – you create a Process; tests it; and then, use Change Set to deploy it to Production.
Process Builder, however, has limitations – for example, you cannot activate a Process which does not have an Action associated with it – as shown in the screenshot below:
Exactly! Then, how can one create a Process with No Action? That is Impossible!
Well, not so fast! Remember, Impossible can transform into – I’m possible! That is exactly what I am going to show you how to do via this blog!
Let us think of situations that may require a User to run a Process without Actions. How about a situation where a System Administrator may want to bypass a Process if s/he is the logged-in user?
Let us look at a simple use case. Suppose a System Administrator creates a Process – with ten criteria nodes – to meet complex business requirements. The Process is working great, as expected. However, last week, the System Administrator received a requirement to update the Process so that it will not execute for users with System Administrator’s Profile! To achieve this, based on the current and native functionality of Process Builder, the System Administrator must add profile check for all criteria nodes to make sure that, none of its criteria nodes will execute when logged-in user’s profile is that of a System Administrator.
Since the Process has only ten criteria nodes (see the preceding screenshot), it would be relatively easy to modify the Process by adding a check for System Administrator’s Profile for each of the ten criteria. However, what if the Process had thirty criteria nodes?! Oouch! Modifying a Process with thirty criteria nodes would be a bit painful indeed!
I should know! For recently, I encountered a similar situation!
So, let us assume that our Process has thirty criteria nodes; and, we want to bypass the Process – for all of the thirty criteria nodes – for a System Administrator’s profile.
Let us work through this via a business use case
Business Use Case
Edward Backhouse is working as System administrator at GurukulOnCloud. At GurukulOnCloud they have just streamlined automation for Sales Processes. To do so, Edward created one Process with thirty criteria nodes. Today, however, Edward received a requirement to bypass this process for System Administrator profile so that, when a System Administrator performs bulk updates to Opportunity records via Data Loader, it will not trigger the Process.
A solution for the above business requirement
There are few possible solutions for the above business scenario – for instance, a User can write a trigger using Apex code that would bypass the process when a logged-in User is a System Administrator.
Most users, however, are not proficient in Apex; and, unfortunately, as discussed above, there is no apparent declarative way to solve the problem. Except one! As discussed below:
Let me show you how the following tools:
- Custom Permission
- A Quick action on Opportunity Object – with no fields added to it
hold the keys to the kingdom!
Creating a Custom Permission
By using custom permissions, one can grant users access to custom apps. In Salesforce, one can use custom permissions to check which users can access certain functionalities. Via custom permissions, it is possible to define access checks that then can be assigned to users via permission sets or profiles – similar to how one assigns user permissions and other access settings. Indeed, one can even use custom permission to bypass validation rule for certain users or profiles!
Not familiar with custom permissions? No worries – just read the following article before proceeding – Getting Started with Process Builder – Part 70 (Bypass Process for a Specific User or Profile)
Let us create a custom permission to bypass Processes. Perform the following steps to create a custom permission:
- Navigate to Setup (Gear Icon) | Setup | PLATFORM TOOLS | Custom Code | Custom Permission and click on the New button. Create a new custom permission, as shown in the following screenshot:
- To assign a custom permission to a profile (you can also assign it to Permission Set), navigate to Setup (Gear Icon) | Setup | Users | Profiles and open the System Administrator profile.
- Then navigate to Apps | Custom Permission and click on the Edit button.
- Now, assign the Skip process builder custom permission to the profile, as shown in the following screenshot:
- Once you are done, click on the Save button.
Creating a Quick Action
Object-specific actions allow you to create records that have automatic relationships to other records, make updates to specific records, and interact with records in ways that you define. We will use a quick action on the Opportunity Object to update the record.
Perform the following steps to create a quick action on the Opportunity Object:
- Navigate to Setup (Gear Icon) | Setup | Object Manager | Opportunity | Buttons, Links, and Actions and click on the New Action button. Create a new quick action, as shown in the following screenshot:
- Once you are done, click on the Save button.
- On the next screen remove all fields from the action page layout, as shown in the following screenshot:
- Once you are done, click on the Save button. If you get any warning pop-up screen, make sure to select Yes.
Cloning existing Process
- Now we will modify the existing process, which we created here. Click on the Clone button available on the button bar. It will open a popup for you. Under Save Clone As, select Version of current process option. It will look like the following screenshot:
- Once you are done, click on the Save button.
- To meet Edward’s new business requirement, modify the existing Process by adding an 11th criteria node to the process.
- For Formula evaluates to true, select Build Formula
- Enter the following formula – $Permission.Skip_process_builder
At the end, process criteria will look like the following screenshot:
- Once you are done, click on the Save button.
- Now we have to add an Immediate action to the process so that we can able to activate it. Click on Add Action (Under Immediate actions), Select the type of action (In our case Quick Actions) – as shown in the following screenshot:
- Once you are done, click on the Save button.
- Now reorder your process criteria! It means, drags the 11th criteria – Bypass for custom permission (which we added just now) – to the first place and make it the 1st criteria of the Process. This means that no subsequent criteria in the Process will be evaluated if logged-in user is a System Administrator – We could accomplish this because we assigned a custom permission to the System Administrator’s Profile.
- Don’t forget to active the Process by clicking on the Activate button.
It’s time to test this feature
Next time, when Opportunity records are created or updated, by the user, the process we created (Using Process Builder) will fire and check the criteria – does the logged-in user have custom permission assigned via Profile or Permission Set? – if so then, the system will bypass the Process completely. You can also check the Execution Log to better understand how SOQL and DML are used in this Process.
Wasn’t that a great journey? Now you know how to turn, triggering of a Process, On/Off, by leveraging the power of Custom Permissions!
Yes, go ahead! Show off your newly acquired skills to your friends, colleagues, and families!
Please feel free to add constructive comments, insights – and yes, challenges too! – to the blog. Good Luck in your Journey towards becoming a Salesforce Ninja!
Note: – I am thankful to Resco.net and Smartcloud.io for sponsoring my blog.
Technical Editor and Proofreader: - Munira Majmundar
Hi,
Thank you for this post which help me.
If it can helps, I find time-consuming and useless to create an action on each object to set up the bypass.
I just create an action ‘update’ on a field with an impossible filter in the action. For example if email = ‘$µ’, I update the field X.
Of course this action will never execute. And it works like this.
Best regards,