Benefits of using a Trigger Framework

If you have multiple triggers on an object you need to be careful.  The order in which triggers run is not known so strange things can happen if triggers conflict with each other. Multiple triggers can work fine if properly designed to not conflict with each other but it can introduce a maintenance and complexity overhead.    Multiple triggers can also consume more resources (soqls etc) and you can start hitting limits.

A much better approach is to have one trigger per object.

To allow this trigger to handle potentially a large number of different scenarios, introduce a trigger handler framework.  This means that the trigger itself is simple – it calls a trigger handler class that will hold the logic.  (So the actual trigger and the logic are separated.)

There are a number of trigger framework examples out there.

https://developer.salesforce.com/page/Trigger_Frameworks_and_Apex_Trigger_Best_Practices

http://developer.force.com/cookbook/recipe/trigger-pattern-for-tidy-streamlined-bulkified-triggers

http://chrisaldridge.com/triggers/lightweight-apex-trigger-framework/

A Trigger framework can help in trigger management by:

  • Providing organisation, standardisation and consistency
  • Reducing complexity
  • Allowing easier maintainability

A trigger framework can introduce some other useful features.

  • Deactivation
  • Recursion Control

Deactivation – To deactivate a trigger can require a deployment, which can be painful and time consuming.

  • Your tests all work with triggers on and off right?
  • What if triggers are needed off for a data update but your devs aren’t around?
  • Someone needs to put the trigger back on when a data exercise is complete.

The trigger framework can introduce an alternative way of deactivating trigger function. The trigger itself is always left on with run control added to the helper class.

Custom setting values can be used to determine if a particular part of the trigger operation should run or not.  Custom settings can be set manually or updated on mass with a dataloader update.  The whole trigger doesn’t need to be activated, you can introduce fine control and allow deactivation of only certain features.

Recursion Control – Triggers completing an update that then causes the trigger to rerun can be a problem.

https://help.salesforce.com/articleView?id=000133752&type=1

They loop for while and will hit a depth limit.  Build in recursion control into your framework to avoid this ever happening.

This entry was posted in blog and tagged , , , . Bookmark the permalink.

Leave a Reply