The Question:
Is it possible for triggers to fire three times when both a Workflow rule and Process Builder workflow are executed?
The Problem:
A DML, Data Manipulation Language, is happening and it causes the trigger to fire. Then, the workflow rule executes and that causes the trigger to fire a 2nd time. Then, the Process Builder flow fires and inside the Process Builder flow, the trigger fires a 3rd time.
When the Process Builder flow is deactivated, the trigger fires twice. When the Process Builder flow is left active and all the workflow rules are deactivated, the trigger fires twice, as well.
The Solution:
The answer is to set a static the first execution, and then not execute again. That will fix it. But be careful in the unit test, after each DML in unit test, the flag will have to be set to false again if you intend to try insert, then update, then update etc., since unit test is "same execution"
Here is how the trigger starts out:
// prevent recursive trigger calls
if(!OfferTriggerHandler.OfferTriggerIsRunning)
{
OfferTriggerHandler.OfferTriggerIsRunning = true;
Further Exploration:
Many might have known the ‘before and after executions’ in the order of executions, but perhaps hadn’t seen that the Process Builder causes a third run. The question arises, as to where the Process Builder runs in the order? A review of the Salesforce Developers Force.com Apex Developer’s Guide: Triggers and Workflow, does not list it in the order of execution running as it did in the example above.
The Process Builder can be set up to cause a re-execution. So one might still wonder if the Process Builder re-triggers from the top of the execution, entirely? The thinking of our team at CRM Science is that it is both Workflow, and Process Builder. One might have imagined that Salesforce would combine Workflow, and Process Builder, into the same steps so they don’t run trigger so much. And we think that’s why it is not good to have triggers and Process Builder on the same Object. If there is already a trigger, might as well keep going with it- it is a different technology altogether.
Considerations For Large Salesforce Orgs
In really large Salesforce Orgs triggers on core CRM objects can become a bane of an admin or developer’s existence if the last group in charge of the org didn’t control usage.
Have A Salesforce Puzzle? Let's Solve It Together! Contact Us Here.
