4

I have two triggers on an object. One contains all before logic and another contains all after logic.

First Trigger:
{
1. if(Trigger.isUpdate)
    {
        for (Task_Flow_manager__c TFM: Trigger.new){
        }
    }
2.  if(Trigger.isInsert)
    {
        for (Task_Flow_manager__c TFM: Trigger.new){
        }
    }
//3. For both insert and update operations:
for (Task_Flow_manager__c TFM: Trigger.new){
        }
}

The first trigger has 3 parts. both 1 and 3 has before update logic. So when the second trigger executes? After the first part finishes or after the whole first trigger executed?

Improve this question
1
  • In addition to @sfdc_ninja's response, if you're looking for best practices on trigger patterns, there are several. The one I like and use is this one: developer.force.com/cookbook/recipe/…
    – cropredy
    Commented Jun 4, 2014 at 23:32

2 Answers 2

Reset to default
4

I don't fully follow your exact use case, but instead of having two triggers on the same object, you should create one trigger and have the before and after logic within it. Triggers have set execution flow within the trigger itself, but if you have two triggers on the same object, one of them fires and completes, then the second fires and completes. There is no way to control which order they fire in either. It's a general best practice to have only 1 trigger per object if possible. 

Trigger myTrigger on sObject (before insert, after insert) {

     if(trigger.isBefore) {
         if(trigger.isInsert) {
             //YOUR BEFORE INSERT LOGIC
         }
         if(trigger.isUpdate) {
             //YOUR BEFORE UPDATE LOGIC
         }
     }
     if(trigger.isAfter) {
         if(trigger.isInsert) {
             //YOUR AFTER INSERT LOGIC
         }
         if(trigger.isUpdate) {
             //YOUR AFTER UPDATE LOGIC
         }
     }
}
Improve this answer
2
  • The poster stated that one trigger handles only before-dml events, the other only after-dml events. Their order of operation is determinate in this case. Other than for code re-use, there's no practical benefit of the design you've outlined here, especially if you don't use utility classes, which may cause the trigger to reach thousands of lines of code and become very difficult to read.
    – sfdcfox ♦
    Commented Jun 5, 2014 at 1:06
  • I would definitely use utility classes, this is just a basic demonstration and didn't want to make it too confusing. I would argue that code reuse is a fairly important practical benefit. Especially to those just learning the language. Also encouraging a single trigger per object is fairly important for those learning the language. There are situations where you go against this practice, but that is more advanced and likely doesn't need to be addressed until someone has the basics down.
    – Chris Duncombe
    Commented Jun 5, 2014 at 12:15
1

The order of execution depends on the trigger events specified. Each trigger's body will be executed in full before moving to the next trigger.

If your two triggers are defined as this:

trigger doSomethingBefore on Object__c (before insert, before update) {
// code
}

trigger doSomethingAfter on Object__c (after insert, after update) {
// code
}

The order of operations will be that doSomethingBefore will fully execute, then doSomethingAfter will fully execute.

Each trigger will be executed only once, unless a workflow field update affects the object, in which case both triggers will be called twice, or if another trigger performs a recursive DML operation, in which case the triggers will execute in a stack.

If both triggers were instead defined as (before insert, before update, after insert, after update), then the triggers will run in indeterminate order (you cannot guarantee which will be called first), and each trigger would be called twice per DML (four times on a workflow field update).

However, in each case, all of the code in a single trigger body will be run, except for obvious situations such as branching statements, before any other trigger will execute. One trigger won't stop half-way through to let another trigger execute, unless you explicitly perform a DML operation that causes other triggers to fire (but, in your specific case, this wouldn't happen).

Improve this answer

You must log in to answer this question.

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