Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

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.

share|improve this answer
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 posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.