Regarding on Trigger Framework for one trigger per object.I wonder is there any risk for this to get CPU Exceed Limit exception compare to the traditional trigger?The doubt is because it only call one trigger and run multiple method.

  • 1
    how would one trigger calling code containing multiple methods be more of an execution cost than all the same code in the one trigger? Separating the code from the trigger is about code management, controlling logic, and code reuse. If anything it should reduce unnecessary processing not increase it. – Eric Jun 15 '16 at 1:47

The "one trigger per object" rule is recommended to help avoid common problems when writing triggers. For example, you'll see questions here, and on other forums, about the order of multiple triggers on the same object with the same event. The answer is simply that you cannot know which the system will prioritize, which can have unintended side effects, such as when both triggers update the same field, or try to update the same related objects, etc. Also, using just one trigger means you can condense multiple queries across multiple triggers into more compact versions, often saving other limits. However, this is a problem even if you use a poorly designed framework instead of a trigger body.

Function calls are not cheap time-wise, and there's limits to the size of the stack, so storing everything inside the trigger body may be marginally faster, but usually that design choice isn't going to be the reason why you exceeded CPU limits or stack limits; the actual time spent calling a function (e.g. simply calling it and ignoring the return value) is about 0.01ms, which I found by running an empty loop 100,000 iterations, then the same loop with a call to a static function, and took the difference (the empty loop was about 0.0001ms per iteration in comparison). A typical framework might have two dozen function calls on particularly loaded objects, which even then only 0.24ms of the total execution time.

There are also other limitations that can come in to play. For example, an entire function can only be 65536 bytes of compiled code, so some really large triggers might need utility functions anyways, at which point you'll start gravitating towards a framework. Also, keep in mind that the CPU limit isn't "per trigger" or even "per namespace". It's the limit for all execution of Apex Code. There's is only one benefit to using one trigger per functional unit rather than per object, and that is related to code management, since having separate files can help reduce overwrites. A good code versioning system negates even that.


Traditional triggers won't give you a larger Apex CPU limit than a single trigger calling multiple methods. The Maximum CPU time on the Salesforce servers limit is a Per-Transaction Apex Limits and is shared across all namespaces.

That makes the question, do multiple individual triggers doing very specific tasks perform faster than a single general trigger that orchestrates methods calls to perform the same tasks.

You would most likely need to look at your specific scenario to determine if the complexity of multiple triggers is worth it.

Certainly if you blindly have a single trigger per object type invoked for all the combinations of before/after insert/update/delete then it could add some overhead.

  • I am thinking about that too especially when it involving high-transaction object such as Opportunity. – unidha Jun 15 '16 at 3:15

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.