Triggers, Workflow, and Process Builder

November 30, 2015

 

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.

 

 

 

Please reload

Recent Posts
Please reload

At CRM Science, we use our Salesforce expertise to transform your enterprise. Partnering with our clients throughout the Salesforce journey, we work with leaders to strategize and optimize business processes, and design and develop solutions across every Salesforce cloud. We empower companies to innovate faster, better engage with customers, and improve bottom lines. 

 

CRM Science is a Salesforce Silver Consulting Partner. Our strategic consulting services were recognized by Salesforce in four consecutive Salesforce Partner Innovation Awards, an annual recognition for partners that deliver outstanding client success. 

Helpful Content
Blog
Events
Client Success
Connect with us
Email Us
860 First Ave, Suite 2
King of Prussia, PA 19406
(484) 775-0333
  • Twitter
  • Facebook
  • YouTube

Copyright © 2011-2020 CRM Science, Inc. All rights reserved.