Check out my previous articles: 

• Getting Started with Process Builder – Part 84 (Ever Needed to Select Multiple Picklist Values in Process Builder? How About via a Single Condition?!)
• Getting Started with Process Builder – Part 85 (Leveraging Versatility of Rule Criteria – a Deeper Dive!)
• Getting Started with Process Builder – Part 86 (What? Create a Process with No Action? Really?)

In the aforementioned articles, I have discussed few advanced concepts that will help you to optimize your process. If you didn’t get a chance to read it yet, do it now! It will significantly improve your knowledge of Process Builder. Once you master the art of leveraging process builder, you will be able to easily create an optimized process!

In this article, we will unravel a known limitation of process builder by understanding the logic behind using filter conditions in Update Records action.

As far as Update Records action goes, currently, as of (Spring’18 release), only the following two scenarios are possible in process builder:

1. When you use a field once, while filtering Update Records Action, then, the process builder will automatically use an ‘AND’ condition between the fields. For example, as shown in the following screenshot, both the fields (Rating and Source) are used once –  and therefore, an AND condition is automatically used between them.

However, there may be times when a user may encounter a scenario where, s/he may need to use a field twice, as shown in the following screenshot:

In the above scenario, the Source field is used twice. In such a scenario, the process builder automatically creates an OR condition between first and the second use of the Source Field. 

Remember, everything happens automatically so, you do not need to define anything. 

Now what happens if I use three different fields, where each field is used only once, to define my filter as shown below?:

In this case, the process builder will use an ‘AND’ condition between all the three fields because they are all used only once while filtering the Update Record Action, as shown in the preceding screenshot.

Got it?

But, now, what if I want to define my own criteria? – as shown in the following screenshot: 

Nope! Can not do it!

As mentioned above, one of the limitations of the process builder is that, you cannot write own filter logic in Update Records action – as shown in the preceding screenshot.

However, we are Salesforce Ninjas and that means, we do not accept ‘can not do it’ without a good try/fight!

So, wait for a second, and think! Is it possible to solve the above business use case using process builder? – if your answer is still no, or even maybe, – then, read-on! It is possible that when you reach at the end of the article you may hear yourself saying – Yes, it is possible! 

Always remember, impossible can transform into I’m possible if you don’t give up! That is exactly what I am going to show you how to do via this blog!  

Let us work through this via a business use case

Business Use Case

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