I searched a bit for some informations about the need to make an update on a record in after insert/update trigger context. I found that the common feedback was to move the Business logic in before context, which is a best practice most of the times.

Anyway, As a programmer I would understand how to execute an update in after insert/update context

  • this because the formula field are updated
  • I can be sure that all the before operations has processed properly and without issues.

In this situation what I have to keep in mind so to avoid issues? With the new DML I'm going to fire a new trigger (before and after), and we hve two triggers on same records that execute in the same context. So what happen to the variables:

  • Trigger.Old
  • Trigger.New

Those are the new variables or the first trigger, or the variables of the second trigger?

How can I controll/master the operations of the two triggers (and avoid an infinite loop )

I'm writing this question so to get a better explaination of this situation, I figured out that there is a poor documentation.

thnks in advance.

  • You have read this? salesforce.com/us/developer/docs/apexcode/Content/… It explains many things, besides before and after triggers. Apr 20, 2015 at 14:36
  • Hi, yes I already read out the document.... but what I would find is to find a way to use as a best practice on those scenarios... Where you may need to execute more DML on same records.... Actually I usually use static variables to avoid loops (based on the trigger logic) , I would find a way to decouple the static variables and the trigger Business logic... I found some info also on the Applemans book, but a no decoupling procedure (decoupling static variables and Business Logic)
    – Klodj_Meta
    Apr 20, 2015 at 14:45

1 Answer 1


In a Before Trigger, Trigger.new and Trigger.old both contain the same values. However, in a Before Trigger, one can operate on the values in Trigger.new and change their values.

In an After Trigger, Trigger.new will contain the the Id's and field values of any records that have been changed by a DML operation. The values contained in Trigger.new can be compared to Trigger.old in order to determine which records meet the criteria for firing the trigger and need to be operated on. Unlike in a Before Trigger, the values in Trigger.new cannot be changed or edited.

Recursion is frequently handled by setting a boolean static variable to "true" when a trigger initially fires. Upon entry to the trigger, that static variable is tested. If the boolean is "true" when re-entered in the same execution context, then the trigger is exited rather than allowing it to run again. There are a variety of methods for handling recursion and this is probably the most common.


I think what you're looking for are trigger patterns such the one described by Dan Appleman in his book Advanced Apex Programming for Salesforce and Force.com (Note: sample code available from App Exchange as an unmanaged package), Hari Krishan's Architecture Framework to Handle Triggers or Kevin O'Hara's Trigger Framework among others that exist or have been espoused which you can find through searching that go beyond the Trigger Pattern for Tidy, Streamlined, Bulkified Triggers.

Using a Main Dispatcher class, these approaches take charge of trigger execution, extending it to an enterprise level application that's scalable, can have it's own diagnostics classes and error reporting, utilize common helper classes and much more. One can also control trigger execution order; something that can't be done with triggers that operate independently of one other without some kind of central control for each object or, as is the case with some architures, potentially for related objects as well.

Discussing them in depth is beyond the scope of this forum, but I'll point you to at least a few posts that you may find relevant including: Controlling Trigger Execution, One Trigger Approach: Any Logic in Trigger?, Difficulties with Appleman's Trigger Classes and General trigger bulkification - best practices.

  • 1) not both Trigger new/old contains the same values in Before... usually they are different 2) OK, normale 3) yes, for a global analysis is used a static boolean, but for a generic structure, and deep analysis/control on execution, what should be used... what happen on the trigger variables when you have 2 or more triggers that execute in one execution context - Trigger 1 (before, after) - Trigger 2 (before, after ) ... - Trigger N (before, after) what happen to the records, and how I can controll the records over the triggers
    – Klodj_Meta
    Apr 20, 2015 at 19:48
  • In a Before Trigger, since no records have changed, initially the contents of trigger.new and trigger.old are identical until you perform some operation on trigger.new that makes a change to it. If you have 2 triggers that run in the same execution context, then you have a different situation where you'd want to combine and manage them using something like the Tidy Trigger Pattern or one of a number of other variations like Dan Appleman's.
    – crmprogdev
    Apr 20, 2015 at 20:00
  • Hi, yeah, I'm already using a design like that on triggers, but actually I'm getting a bit anoing on those scenarios... Actually I'm trying to create an automation that use triggers to push forward processes to next steps. This part actually is designed to execute in trigger context (after), and I'm getting some trouble on controlling more triggers on same records in a same context... so I opened this question to understand a bit more the behaviour of the triggers...
    – Klodj_Meta
    Apr 20, 2015 at 22:34
  • See my edited response. I think this will point towards the information you're looking for.
    – crmprogdev
    Apr 21, 2015 at 17:07
  • crmprogdev, great answer! There is an exception to the "Trigger.new and Trigger.old both contain the same values" in Before context that's tripped me up before, so I thought I'd point it out: Jan 28, 2017 at 7:40

You must log in to answer this question.

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