2

Is it good practice to allow a trigger to run multiple methods at once? For instance, if I had two methods I wanted run before insert, could I do the following?

if(trigger.isbefore){
object.createName(record);
object.updateCheckbox(record);
}

My concern is that since they both have an Database.SaveResult[], that they will both run individually and that if there is information in the second one that is important to run before saving it won't wait until after the second method to save. But what if I want the code from updateCheckbox() to run on insert as well?

So would I have to save the code from updateCheckbox() and put that into the createName() method? Then have the updateCheckbox() method on trigger.isupdate?

7

To directly answer your question, yes, it's common practice to include multiple methods or pieces of functionality in a trigger. Methods are run in sequence, and any exception that occurs in any of them, if it's not caught, will result in rolling back the transaction. Nothing is committed to the database until the entire trigger execution completes successfully.

I'm not sure why you have Database.SaveResult[] in a before trigger. You don't need to perform DML to save changes you make in before triggers (provided, as @DerekF notes below, that you're changing records referenced from Trigger.new or Trigger.newMap).

This is a great place to start thinking about using a Trigger Handler framework. There's lots of material available about these frameworks, and even examples you can take and incorporate into your own code. Here is a starting point for reading.

What a trigger framework does for you is create a structure where you can define and be consistent about which operations (or method calls) happen in response to each trigger event. It's very easy for complex triggers to become difficult to manage and debug; a trigger handler framework helps organize your code and prevent future issues.

| improve this answer | |
  • Might be worth mentioning that the "no DML required" feature of before triggers is limited to the records held in Trigger.new and Trigger.newMap. Only changes made directly to the object instances referenced by those two trigger context variables are saved to the database without DML. SObject rec = trigger.new[0].clone(true, true, true, true); rec.put('myField__c', 'my updated value'); won't see the value of myField__c updated without DML, while SObject rec = trigger.new[0]; rec.put('myField__c', 'my updated value'); will (assuming this is part of a before trigger). – Derek F Dec 28 '17 at 16:20
  • 1
    So to be sure I understand the info you linked... basically the idea is to handle all of the logic in the class and not in the trigger? The trigger would just kick you to the class and then the class methods would define when they are fired? – Chance Dec 28 '17 at 16:34
  • 3
    Yep, that's the core idea of a trigger framework. – David Reed Dec 28 '17 at 16:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.