Six Do's and Don'ts for Salesforce's Process Builder

An important note: Salesforce no longer supports Process Builder, and anyone with active Process Builders in their org needs to be actively converting them into flows. Please reference our Ultimate Guide to Salesforce Flows for further help, or reach out to us using the Contact Us form at the bottom of this page.

It was the Spring of 2015. Flowers were in bloom, birds were chirping, and off in the distance, the sounds of Salesforce admins cheering in delight could be heard. For gone were the days of having to write Apex just to stamp a value in a lookup field or update child records! It was the GA date for Process Builder, and admins eagerly anticipated the freedom that this new automation would bring.

But as Uncle Ben once said, “With great power comes great responsibility.” And it wasn't long before many admins learned (often after encountering their first CPU timeout) that Process Builder was not simply Workflow Rules 2: Electric Boogaloo, but rather, a tool that was incredibly powerful and necessitated a high bar of responsibility.

As a Solutions Architect here at Kicksaw, whenever I am handed a new (to me) Salesforce org to work on, one of the first things I check is the health of the business processes made with Process Builder, as they seem to be a common spot for a lot of bugs and errors. In this article, I’m going to share some tips and tricks with you to ensure that your own Process Builder business processes don’t turn into a nightmare of timeouts, bugs, and unexpected data.

Only use one Process Builder business process per object

When you have a single business process per object, by default, you only have one place to go in order to see everything that is happening with that object. And when there's only a single business process, you can rely on the automation to fire in the correct order. When you have multiple processes, all guarantees go out the window — with multiple processes on a single object, you have no control over which one fires first, which could lead to unnecessary headaches and unexpected results.

ISNEW and ISCHANGED are your friends

The most common issue I see, even with otherwise competent admins, is the misuse or neglect of ISNEW and ISCHANGED. This applies mainly to business processes that fire on create and edit. Each node that fires off actions puts a toll on the system, and while this won’t harm you in the short term, in the long run you’ll notice that editing or creating a record takes longer. In worst case scenarios, this extra toll will result in timing out, especially when other automation may cascade and trigger the Process Builder to evaluate. I’ve never run into a scenario where a node’s criteria couldn’t contain an ISNEW() or an ISCHANGED() (or have that nifty little checkbox under Advanced checked). Think about the actions that should trigger the automation and work from there.

Fewer nodes = greater efficiency

Each node in a business process needs to evaluate in order to determine whether or not its actions should fire. What this means for you is that every node will increase the processing time of a transaction by incremental amounts. While having extra nodes may not make or break your Salesforce instance by itself, if we compound this with other performance issues, you may experience slower processing times and the dreaded CPU timeout. Never mind how hard it can be to find out where automation is firing from, or how it should be ordered when a business process has multiple duplicative nodes. If certain actions that fire off of the same criteria tack onto the same node, check what exists first before deciding to build a new one.

Fewer actions per node = even greater efficiency

Limit the number of actions per node as much as possible, to the extent that it makes sense to do so. If you have two separate actions in a single node updating the same record, that counts as two DML statements. Combine these! Use formulas with a field update, instead of filtering records with the action criteria. If you want to ensure that a particular field's value doesn’t change, you can always use an IF statement. Say something like IF([Criteria] = TRUE, New Value, [Field API Name]). By putting the field as the false criteria, Process Builder will actually preserve whatever value it was when the process originally fired.

Don’t check the Recursion checkbox

If someone has a valid use case for this I’d love to hear it. What this checkbox does is simply make the Process Builder evaluate up to 5 times in a row. Just don’t check it. Don’t.

Flows are the future!

If you have been living under a rock the past year, you may not have heard about these nifty little things called record-triggered flows. If that's you, get ready to join the revolution! Record-triggered flows allow you to do just about everything that Process Builder can do and more, via the Flow Builder. What's more, they handle these tasks more efficiently than business processes. There are some big feature enhancements coming in the Summer ‘21 upgrade (and beyond) that will continue closing the gap and lowering the use cases for business processes. Start looking into and learning more about flows if you haven’t already — with every release, Salesforce is putting more and more automation into flows that used to be only possible with Apex. They are the future!

So there you have it! Those are six pieces of my best advice when working with Process Builder. There's of course a lot more to creating an ideal workflow for your Salesforce instance, but these tips will get you going in the right direction. If you need more help, you can always reach out to us at Kicksaw — we'd love to help you build the solution that's best for your business!