Salesforce Sidekick

I am working on a mini-series related to understanding Bulkification (related to Process Builder and Visual Flow).   So, you’re going to see a theme of posts like this and Building your Process Builder for Optimum Performance and Bulkification where I focus on some design considerations with Process Builder and Flow.  The reason behind these posts are because Process Builder and Flow are extremely powerful tools that give those previously developer-only powers to the masses.  And as we all know… with great power comes great responsibility!  So, lets do our part to make sure that we build our Process Builders and Flows in a way that would not cause developers headaches.  I’ll cover the basics of the different types of criteria, and then go over why it matters that you take building criteria seriously.

When setting the criteria for our Process Builder to fire, our options are:

1. Conditions are met
2. Formula evaluates to true
3. No criteria – just execute the actions!

Lets dive deeper into each of these and talk about when and why would use them, and some of the common mistakes that are made around these.

Conditions are met

Using this as our criteria gives us a few more options than what we used to have with Workflow Rules criteria.  Now, we have operators like Is changed and Is null that were previously unavailable to us.  Outside of those new options it is essentially just a cleaner UI.  Don’t forget about the ability to make your Value a Formula (see condition #3), you can use awesome functions like PRIORVALUE and grab in cool System things like your Custom Settings!  Speaking of, Jennifer Lee has a great post on using Custom Settings in Process Builder that is a must read for anyone not familiar with Custom Metadata or Custom Settings!

So we can pretty much do pretty much everything inside this criteria option… but what are the pitfalls that we will run into?

Forgetting to check the Advanced checkbox.

I really wish that Salesforce didn’t hide this section, it needs to be front and center!  I feel like this is one of the biggest errors that people make when building a Process Builder.  It is often overlooked until you’ve got a Process Builder that is creating a record or sending an email, and you realize that you’ve just had six emails get sent out to a Client!

Using Is changed

While I absolutely LOVE this operator that Salesforce gave us within Process Builder, the fact of the matter is I have seen tons of Success Community questions where people get stuck on this.  It isn’t documented very well that Is changed will ONLY run on Updates.  This will not run on Create.  That means, you’re up a creek without a paddle if you’re trying to build your Process Builder to only fire when a value changes, but also have it work if that field has been filled out on create.  If anyone has a clever way that they’ve found to bypass this issue, I’de love to hear it.

Formula evaluates to true

While not as simple as the conditions are met option, this gives us the ability to do everything that we would want to do.  The problem is that this often is more fragile than the rest.

API Field Name Changes

This option unfortunately will NOT update your formula if you have to change the field name.  Keep this in mind, because just about everywhere else in the UI this is something we’re accustomed to.  You will however be greeted with a lovely error message anytime you try to Clone ur Update your Process Builder

Is changed for new records works!! kinda…

Here is a simple example of how you could use the formula evaluates to run on new records and still run ischanged on updates.

We essentially have separated our criteria into On record create and On any updates.

(ISNEW() && NOT(ISBLANK(field)) || ISCHANGED(field)

In my below example I only have to use ISNEW() because the Case Status is always filled out.

No criteria – just execute the actions!

This should not be used unless you have a very good reason.  Just because we have a simple action does a Record Update and nothing else does not mean that we want it to always fire on every edit.  This means that every single edit our Process Builder is firing.  How many situations can you think of that actually require a Process Builder to fire every single time?  Don’t be a lazy Admin and use this option just because you can!

Why does this matter?

Because of how Salesforce ‘bulkifies’ our Process Builders and Flow!

https://releasenotes.docs.salesforce.com/en-us/winter16/release-notes/rn_forcecom_process_bulkification.htm

The issue is that as we continue to customize an Object with more and more Process Builders and Flows you keep adding to the string length!  Remember that every simple Record Update in your Process Builder, no matter how simple, counts as an actual query that will be added into that ‘bucket’.  Previously with Workflow Rules you never had to worry about those simple Field Updates running on every edit of the record, but now as we try to keep our Process Builders and Flows bulkified it becomes an issue!

By fully understanding our Process Builder’s criteria (and using it correctly), we are able to cut back on the extraneous actions.  This results in two big things:

1. Reduced process time when you hit Create or Edit a record
2. You’re more bulkified due to a decreased the number of queries

Which means you’re now the hero of your Org!