Looking for someone to confirm my reasoning on this.

I am working in an org where I just found A process builder on the Case SObject. This PB has 19 nodes. It calls a flow that has 19 possible sub-flows it might invoke.

If I have a case that meets the criteria of PB Node 1 --> it calls Master Flow and master flow calls the sub Flow that contains the logic for PB Node 1 condition.

Sub-flow 1 does its thing -makes some field updates on the case and invokes DML by calling update records;

We fire our Case Trigger again and then roll back into the Case Process Builder that will check nodes on this same case.

Even if that case met the criteria for PB node 2 the first time it passed through, that would not have been invoked because of the DML on the case from the sub-flow? We have to wait for that case to get picked up by the PB a second time and evaluate it against node 2.. and so on down to node 19.

I am right that this could potentially result in 19 operations to update a case. Although the latest order of operations info graphic says that area is limited to 5 iterations.

1 Answer 1


In the Process Builder, Salesforce first evaluates every node on the first iteration. For each node, if the criteria is met, the node's actions are queued, and the "Specify What Happens After Evaluating This Criteria" is checked. If set to Evaluate Next Criteria, then Salesforce will continue to evaluate nodes until either a Stop is encountered, or the last node is evaluated.

Until this point, no Flows, Field Updates, etc have been executed. Each sub-flow will then be executed in order, one at a time. If there are multiple nodes that call the same sub-flow, Salesforce can aggregate those together (see Flow Bulkification in Transactions for more information). If there are any Field Updates, those are all aggregated together and executed at once, and if the "allow recursion" option on the Process Builder is checked, all nodes are evaluated a second time. This entire process can happen up to six times (the original iteration plus five recursions).

All of this means that, in theory, a Process Builder with 19 nodes could theoretically trigger upwards of 114 separate save operations. Of course, you'd have to go out of your way to actually get that many operations in a single transaction. Just as a hypothetical situation, it's quite possible to build a system that is very slow and inefficient.

  • Great answer! Thank you so it looks like this is not the disaster I was worried about. Feb 15, 2023 at 23:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .