We have a core app (managed base application) and want to extend it with add-on products. We plan to use managed extension packages for this.

It is crucial that we can extend and/or overwrite triggers from the base package, but I did not find anything on how to do that?

If the base package and the extension define a trigger for a custom objects, how are they called and when?

Any ideas on how to solve that?


There is no platform support to allow you to overwrite managed Triggers or disable them in a base managed package from an extension package. Extension packages can add their own triggers, but the order of execution is not deterministic.

One consideration is to leverage an Apex plugin strategy to expose a global Apex Interface from your base package which your extension package code implements in its own classes. Your base package uses the interface to communicate with the extension code during the base trigger execution, as such the extension package does not have any triggers in it.

In your base package (namespace mybase in this example) something like this...

global interface ITriggerExtension
    void onBefore( ... );
    void onAfter( ... );

In your extension package something like this...

global class ObjectATriggerExtensionImpl implements mybase.ITriggerExtension
    global void onBefore( ... )
        // Do some extension logic

    glboal void onAfter( ... )
        // Do some extension logic

From the base package trigger use the Type.forName method to lookup the extension package class and the Type.newInstance method to create an instance you can cast to your interface, allowing you to call extension logic from your base package trigger logic.

Resolving the Trigger Plugin Classes

In respect to knowing which class in your extension package the base package looks for, you have a few options depending on how flexible you need things to be and if it is a closed plugin API just between your packages. For the later you could simply have a naming convention approach (tied just to look for classes in your extension package namespaces) or if you wanted something more configurable in the subscriber org some Custom Settings (possibly protected ones only accessible via Subscriber Support). The benefit of a naming convention is it is self configuring.

  • Already a great answer! But to invite a broader range of answers and experiences I decided to leave my question "unanswered" for a few more days ;-) – Robert Sösemann Feb 5 '14 at 8:14

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.