Trigger + Process + Workflow = Recursion Hell?

As your Salesforce org matures, chances are you'll find yourself trying to untangle Apex triggers, processes created with Process Builder, and workflow rules. Specifically when field updates are involved, predicting the outcome from the order of operations can be a pita, especially because the documentation still leaves room for questions in cases involving recursion.

Follow the two rules below for a reduced-pain implementation.

• One trigger per object
• No autolaunched flows. Use Process Builder, but avoid invoking autolaunched flows. If you've already got a trigger involved, whatever you need to do in an autolaunched flow can be handled in Apex, with the added benefit of Apex tests to cover yourself.

If you're updating fields on a in Process Builder, and you've marked the "Recursion" checkbox, know that every time the record is updated by the process, before and after trigger events will fire again. This is also true for updates made by a process invoked as an action by another process.

So all in all, remember that a single Apex trigger could run 14 (fourteen) times for a single DML operation! If you're mixing triggers with processes and workflow rules, make very sure your business logic in triggers will survive recursion.

Field Update + Update Records + Apex Trigger = ?

While the "Triggers and Order of Execution" page in the Winter '16 Force.com Apex Code Developer's Guide gives good information about the high-level order of operations, developers reading it are still unclear about how complex interactions unfold across objects that use workflow rules, Apex triggers, and Process Builder ("PB") processes.

Let's take a relatively simple set of automation applied to a single object:

• A workflow rule with a field update
• A recursion-enabled process that updates the record which starts the process
• An Apex trigger

When a transaction is processed, how many times do each of the above automation components execute in that single transaction? The answers below may surprise you/

Component Type	Num Executions
Workflow Rule	1
Process	6
Trigger	8

The exact step order in which the components were executed is illustrated below.

Workflow Rule	Process	Trigger
		1
2
		3
	4
		5
	6
		7
	8
		9
	10
		11
	12
		13
	14
		15

The takeaway should be that developers ought to be very careful when adding automation to an environment that uses "all of the above", meaning workflow rules, processes, and triggers.

Where's My Flow/Process in the Change Set?

If you've tried deploying flows or processes in a change set, especially in a large change set, you may have experienced some disorientation trying to find that in the Change Set detail page. For quick reference, the table below shows you what you should be looking for when examining an open change set vs. a closed change set.

Component Type	Ordered By (in Open Change Set)	Ordered By (in Closed Change Set)
Flows	Unique Name	Flow Name
Processes	API Name	Process Name

Recursive Process with Autolaunched Flow

In the old days of Salesforce, if a workflow field update occurred during a DML operation, the before and after triggers would for that object would execute a second time. But in the new world of Process Builder with autolaunched flows, how does the order of operations play out?

The Spring '15 documentation seems to imply that processes only fire once. The reason I say this is there is no corresponding explanation for processes in the same vein as the explicit explanation (shown below) for how a workflow rule can cause triggers to fire again.

As with many things in Salesforce, I like to trust and verify. And I found that Process Builder processes actually can cause triggers and the process itself to execute up to five (5) more times. I couldn't find this documented anywhere, but that seems to be the de facto limit on process recursion.

The proof

To prove this to myself, I decided to stage a manual test based on the following constructs:

• A custom object named TriggerEvent__c exists as a child to the Account object
• An Account trigger exists to create a TriggerEvent__c record before update
• A process exists that launches a flow, which increments the Num Employees value by one if Num Employees is not blank

Under this setup, when I updated an account and entered 100 for Num Employees, I actually ended up with 106 for Num Employees and six new child TriggerEvent__c records.