How is it possible for triggers to fire three times on a single save of a record? There are many reasons this can happen in the Salesforce1 platform. Our problem had to do with Workflow and Process Builder. We were expecting only 1 extra trigger to fire because we were using workflow field updates and process builder field updates, figuring that the additional DML would be grouped at the end and fire one more time. But instead we found 2 extra triggers fired.
A DML (Data Manipulation Language) operation 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 answer is to set a static variable during the first execution, and then reference this variable to determine whether or not subsequent code should be executed. But be careful in the unit tests; 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 each unit test is in the same context and considered the "same execution."
Here is how the trigger starts out:
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. On "busier" objects or objects prone to bulk inserts/updates through data loads, you may find yourself avoiding introducing processes into the mix. If you have the capability to do so, stick with triggers; at least, for now.
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. Stick to as few triggers as possible per object (ideal is one), as little logic as possible within the trigger bodies, and utilize a common trigger handler method for further processing. For developer friendly orgs, consider the creation of a control system, like a Custom setting, to easily enable and disable home-brewed triggers in your Production environment.
Have A Salesforce Puzzle? Let's Solve It Together!
Contact Us Here.