Avoid Multiple Triggers in Managed Object

Question

Is there any official best practice, approach, recommendation, solution, work around, etc. for the scenario were we would want to extend a managed trigger actions?

This topic has been discuss in some places:

• Disable trigger which comes from a managed package from firing
• Order of execution managed vs. non-managed code
• How to deactivate a managed trigger in a customer org for Mass-Data migration
• How can I stop a managed trigger from executing while running a test class?
• Static variables across multiple triggers in same context

What I want to avoid, is having multiple triggers in a custom object from a managed package, since 'Multiple triggers on the same object often leads to redundant queries being executed, which makes it more likely that governor limits will be exceeded.'Best Practice: Streamline Multiple Triggers on same Object

Notes: I don't want to stop the current trigger actions, I just want to create new ones.

Answer 1

Each managed package should have at most one trigger per event per object. Each namespace gets its own query limits, so governor limits will not be exceeded simply by having one trigger per namespace. Limit yourself to just one trigger per managed object, and minimize the queries you have to do via static variables, if possible. The best practices information basically applies only to being within a single namespace.

The worst thing you need to watch out for is CPU limits, which is global for all namespaces (e.g. the entire transaction). You can't really control other people's (managed) code, but as long as you make a best effort to minimize your own impact to the total transaction. Most of the time, simply minimizing your own queries, leveraging indexes, using a minimum number of triggers, etc, will suffice. Do feel free to create a new trigger, just remember to keep your code optimized.

Answer 2

Not sure if this is within the scope of the question, but I suggest there is a significant difference between including a trigger in a managed package that acts on a standard object such as Account or Contact or Task or Attachment or Note and including a trigger in a managed package that acts on a custom object that is included in the managed package.

If a managed package that contains triggers on standard objects is installed in an org along with several other managed packages and locally added trigger code, then there is the possibility that triggers from all of these will run when a standard object is modified. There is no way to make the order that the triggers run determinate and as sfdcfox notes the CPU limit - and less dangerously but perhaps noticeably the org's responsiveness - will be affected by all the triggers. So these triggers should be as selective as possible about which changes make them perform expensive operations - which field changes or which record types or which parent object types. Perhaps even individual custom settings should be included in the managed package to disable the individual triggers (in a last resort situation).

Triggers in the managed package that act on the custom objects in the managed package do not face this problem of shared use of the objects. At most there might be additional locally added code (that can be edited or turned off) used for customisation. Again the order is indeterminate (unless the managed package author offers extension via interfaces and Type.forName rather than triggers) which is not ideal. But the risks are lower in that there are only two sets of code interacting rather than (potentially) many.