Why Process Builder is the Secret Ingredient to Salesforce Admin Superpowers

Why Process Builder is the Secret Ingredient to Salesforce Admin Superpowers

Take a look under the Process Builder Hood

What is a Salesforce Process Builder?

First, let’s talk about what a Process Builder is. At a very basic level, it’s a way to make really cool things happen within Salesforce that will make your manager very happy. But it’s so much more than that!

As defined by Trailhead, “Process Builder is a point-and-click tool that lets you easily automate if/then business processes and see a graphical representation of your process as you build.”

What can I do with Process Builder?

There are many SUPER handy ways to optimize Process Builder. We can:

  • create/update records
  • send emails
  • call a Flow
  • call other Process Builders
  • post to Chatter
  • send custom notifications
  • …and much more!

Ok, so how do I use Process Builder?

(Creating the Process Builder)

Let’s start at the very beginning. When creating a Process Builder you need to give it a name, a description, and you need to set a “trigger.” That simply means that you must pick when you want the process to start. The trigger can be set to run your process in two situations:

  1. Only when a record is created
  2. Whenever a record is created OR changed

A record change means that this record has been edited in some way, and yes, even creating the record means that it has been changed.

Now we get something that looks like this:

pasted image 0 2


(Object of the process)

When we click “+ Add Object” we are presented with a picklist of Objects we can choose for our process to interact with, and set our trigger to run the process as we see fit.


So now that we know what Object we’re dealing with and we when this Process Builder is going to fire, we can set the criteria for which we want our Process to activate by clicking on the “+ Add Criteria” section. This is simply the “if” part of an “if/then” statement. We can define the criteria that we would like our process to meet in the “Set Conditions” section, where we can make a formula field or just run it.

In this example, we are looking for scenarios where the Contact’s phone number field is blank, yet their corresponding Account phone number field is populated. If that scenario appears, then we want our automation to kick in.

pasted image 0


Now that we have something to trigger our Process Builder, we need to tell it what to do. In the example provided below, we are performing a Record Update where we are automatically updating the Contact’s phone number with the telephone number populated on the related Account record.

pasted image 0 1

Hm… Isn’t this just like Workflow?

Now you may be thinking this looks and sounds like a Workflow Rule and I would say, yes, in some ways, but no – in so many more. It is important to note that Process Builders cannot send Outbound Messages natively. However, Process Builders allow you to make a path for your record to follow as seen below.

pasted image 0 3

Notice the “Evaluate the Next Criteria” option. This means that if your record has gone down this path and has executed the action it can now move onto the next condition, and see if that one is True. You can also configure the Process Builder to simply complete the automation cycle at this point. If so, it will just end. Otherwise, it will continue processing the next node, as specified in the configuration of the Process Builder.

A word of caution

Process Builder is a very cool tool that gives the admin lots of power, and, in the wise words of late Uncle Ben, “with great power comes great responsibility!” While this tool is an incredibly useful and powerful one, it is very important to be aware of what you’re doing as to not create processes that will cause more trouble than good, leaving you with a very unhappy manager (and users). If you misuse this tool you can have slow record loading speeds, data loading issues or endless errors that your users will struggle to get past. 

What can I look out for when setting up my Processes to avoid making a mess?

If you have more than one Process Builder per object you could be causing yourself and your users an unnecessary headache. You see, when you have more than one Process Builder set for a particular Object, they all fire simultaneously any time they’re triggered.

For example, if you have 5 Process Builders on an Account and you make an edit to that Account, you have now launched all 5 Process Builders even if they don’t end up doing anything! Doing this would force Salesforce to review, evaluate and execute multiple simultaneous automation routines on the same record. Multiply that by many records (like in a bulk import or bulk edit) and multiple processes, and it can bring your organization’s entire system to a screeching halt.

Now let’s say your Process Builders are making updates. In these scenarios, the system will continuously attempt to update your records up to 7 times each, triggering errors with each failed attempt to execute the automation you’ve configured. I have seen plenty of Process Builders that update each other and cause this type of effect.

The Golden Ring (the key to saving yourself from making a mess of your Processes)

Pro Tip:

One of the BEST ways to prevent this type of issue (and also make debugging a whole lot easier) is to make a Master Process Builder that controls when all the others are fired. I call this the “Think Before your Build” stage.

Work smart, not hard

It’s best to map out what you want to happen and leave some room for growth. We all know there will inevitably be changes that need to be made, so if you build your map with the future in mind you can accommodate those changes as they come.

Now that we have our map, we can figure out our origination, or starting point, which should be contained in the Master Process Builder.

One very common mistake (and easily avoidable, too) is when a Process Builder is configured to take a value from one record and place it into another record…yet the value being copied is not populated.

For example – if we want to populate a blank Contact phone number field with the phone number field of the parent Account, this is relatively simple to achieve. But…what happens when there isn’t a phone number in the Account record either? Well, depending on how you structured your Process Builder, you might get an ugly error.

The easy way to avoid this is by configuring your trigger to confirm that the Account phone number is not null (not blank) and the Contact phone number is null (is blank). Only then, should the Record Update get executed.

Now, I normally get the question, “So how many Process Builders can I have on a single Object?” The answer to that is two. Two Masters. One for actions that should fire only on the creation of a new record and the second for processes that should fire on edits. This method for organizing your Master Processes is similar to the logic that most developers should be following when creating triggers, except they can do it all in one.

Watch out for those traps

The first trap that some admins don’t know about is the Limits of Scheduled Actions. In case you didn’t know, you can have up to (and no more than) 50,000 pending scheduled and paused Flow interviews. Yes, this is the max total of Process Builders and Flows. Now, on the surface that looks like a lot, but think about this; if you have more than 50,000 Accounts and you build a scheduled action that is set to be enacted for all the accounts, you have now reached your limit on only accounts.

You might say, “But that’s alright! As soon as the action is performed, it no longer holds up the queue.”

Not so fast.

If your action is scheduled for 6 months from now, that means you have 6 months where no other Schedule Actions can be placed in the queue.

The other downfall of Schedule Actions is that they have to be on the Master Process Builder. Because of this, you can’t call them in invocable Process Builders, so be mindful when using them. When a Process builder has a Scheduled Action, even after deactivating the Process Builder, the Scheduled Action will still run. Also, if the Salesforce User that triggered the Process Builder action has been deactivated, the Scheduled Action will fail.

If you need Schedule Actions, the best way to combat these issues is to use an Apex Batch Job or the new Scheduler in Flow.

Most Admins have now seen this error.

The most common reason for this error is that a Null Check was not done on the Lookup field. This is because Salesforce will attempt to query a value related to another record, specified in a lookup field.

For example, on an Opportunity, Process Builder will attempt to find a value based on the Primary Contact lookup field. If the Opportunity in question does not have any value populated in the lookup field (Primary Contact), the Process Builder will result in an error, which will cause frustration for users.

Now, you can enable the Critical Update that allows you to not have to check, but I like to still use Null Checks mainly because you don’t want to run unnecessary processes.

As I mentioned before, I like to use Null Checks as gateways to launch other flows. Below is a Simple Lookup Null Check.

If your trigger is based on a numerical field, and your criteria is “less than or equal to zero” your Process Builder will trigger, even if the field’s value is blank, because that will be translated as a zero. In these situations, you might want to consider adjusting your trigger to “is null.”

As a word of caution, you cannot use a formula field to trigger a Process Builder. You can, however, select any field that is editable to trigger your Process Builder to start. That’s what Scheduled Actions, Apex Batch Jobs and Scheduled Flows are for. Rollup Fields, on the other hand, will trigger a Process Builder to fire, so you can rely on them.

Process Builders and Large Data Volumes do not work well with each other. They are Bulkified but not to the level that can support large amounts of data coming in. The biggest issue that you need to look out for is the updating and creation of records because this can trigger other automations including Process Builders. The other reason why is that if you are making records you may be updating the sharing behind scenes.

So you may be thinking, “how do I avoid these types of issues?” Try out any of these tricks to save yourself the trouble:

  • You could limit the Batch size of the job. This may get your Process Builders to work but it may take a longer time for your data to upsert.
  • The next option is to deactivate each of your existing Process Builders (one at a time) in order to test out and determine which one is at the root cause of the issues you are experiencing. If the issue is a one-time thing, this is a good solution for you.
  • If this is a daily issue, and you are working with an Object that has large data set to it, your best bet is to use a bulkified trigger.

Need more help?

If you’re new to Salesforce Process Builders and want to learn more, check out some of these great resources:


Similar Posts