Are trigger frameworks ALWAYS necessary?

When working on an org with a few simple requirements for triggers, I feel that using a trigger framework easily bloats the code base and a bit overkill as well. I admit this is short-sighted as requirements change in time, but until then, I feel there’s very little reason to use a framework. Not to mention, customers with smaller orgs tend to have stricter time & cost restrictions.

When should a trigger framework be applied? Are there other factors that determined a framework’s necessity?


I think a Trigger Framework is necessary in all but the simplest of orgs. As soon as you have two separate requirements for the same object, then go to a trigger framework. I definitely agree with dphil that eventually they are necessary, so just bite the bullet and go for it.

By using a framework, you can gain several benefits including:

  • Recursion Control
  • Order of Execution Control
  • Inclusion of switches to
    control firing of triggers, methods

The hard part is deciding what framework will work for you. I’ve been using the TriggerX pattern with success in my org. Once you’ve gained an understanding of how to code against it, it isn’t any slower than writing your own triggers. There are a 1000 ways to implement a framework, so you may prefer something else.

Source : Link , Question Author : Jan Julian , Answer Author : Daniel Hoechst

Leave a Comment