function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
learningsfdcdevlearningsfdcdev 

trigger best practice

Wanted to write this post on what the best practice is for trigger architecture pattern. I have heard mixed things.

 

1.  There should only be 1 trigger per object with the trigger context seperated within the trigger to call certain classes.

 

 

2.  An object should have more than 1 trigger with each trigger having  seperate context.

     For example

     -trigger 1:   AccountBeforetrigger with context methods of isInsert, isUpdate etc..

    - trigger 2: AccountAftertrigger with context methods of isInsert, isUpdate etc..

 

Also, if #2 is the preferred approach, should there never be more than 2 triggers per object which seperates the concerns by before and after.

 

Thanks,

 

Abhi_TripathiAbhi_Tripathi

First option is perfect for the triggers, whenver you want to change anything in your trigger just go for its separarted class, 

 

Whenever the record is mass Updated or inserted Object will need to call only a single trigger.

 

Thanks

learningsfdcdevlearningsfdcdev

Hi Abhi,

 

Sorry but your thread doesn;t make sense to me. Can you tell me why the first approach is a better pattern and can you also provide an example.

 

Thanks

Satish_SFDCSatish_SFDC
Not sure if this is a best practice, but i normally use a single trigger with all the trigger events.
Inside the trigger, i separate the code based on the events (isAfter, isBefore,isInsert, isUpdate etc).
The trigger only acts a dispatcher. The actual processing takes places in various classes (or a single class per object).
This way, if i have to perform the same operations for say the before insert and after insert, i call the same static method from the dispatcher (Trigger).

Regards,
Satish Kumar