I started working with Salesforce in 2015, and since then I've been told by mentors and the Salesforce community on the Internet that having multiple triggers for a single object is bad practice, mainly because the platform does not guarantee a trigger execution order. This makes absolute sense in a scenario where there is a single application being developed.

Considering a scenario where an enterprise customer wants to build different applications on their platform though, I think this recommendation doesn't make that much sense anymore. It is like having two installed AppExchange apps that have their own triggers on standard objects (like the Account).

So app A and B can have a trigger on an object, but as long as their logic are separate (logic from application A doesn't depend on logic from application B) there should be no issues. Does this make sense?

  • 1
    It still makes sense to keep to one trigger per object where it is possible to do so. Adding that layer of complexity to your investigative efforts can be a real nightmare. – Adrian Larson Nov 12 '19 at 17:53
  • My main concern is about dependency. When logic is centralized in a single trigger (which may or may not implement specific handlers for code readability), it also creates dependency on everything that is referenced by the code. If two separate apps implement different fields on the account object, and both fields show up on the trigger, then the fields are no longer specific to each package, but common to a "core" package. Seems worse than separating in two triggers, one for each app, to me. – Renato Oliveira Nov 12 '19 at 17:56
  • 2
    Renato - in DF18, there was an interesting talk by John Daniel and advanced talk on how one uses the fflib pattern, dependency injection, and 2nd generation packaging to accomplish a one trigger per object but different apps exploiting the same logic – cropredy Nov 12 '19 at 20:20

It does indeed make sense if you can easily split the logic of the applications. But the question is why would you do it? That will require extra maintenance as the new requirements are coming in and you may end up with duplicate code which is a bad practice itself. You will also probably end up doing the same check(which application is running now and which trigger should be executed) multiple times instead of a simple if-else.

What I would strongly recommend is still 1 trigger per object that just calls a handler class and in this class you can split the logic into whatever you need.

For example:

public without sharing class TRIG_MyCustomOject_Handler implements ITriggerHandler {
    public void BeforeInsert(List<SObject> newItems) {
        List<MyCustomObject__c> scenarioOneList = new List<MyCustomObject__c>();
        List<MyCustomObject__c> scenarioTwoList = new List<MyCustomObject__c>();
        for (MyCustomObject__c mco : (List<MyCustomObject__c>)newItems) {
            if (mco.MyCustomBooleanField__c) {
            } else {
        if (!scenarioOneList.isEmpty()) {
            // Call methods to do your scenario 1 logic
        if (!scenarioTwoList.isEmpty()) {
            // Call methods to do your scenario 2 logic
        // Call methods to do some generic logic if any

I hope this makes sense

  • Why would I do this? To separate logic and to avoid the centralization of dependencies in a single package. The way you described, if the class implements fields from both applications, then the package depends on those two, but the logic should be owned by the package, not to depend on it. So my question is now regarding your answer: how does that work in a scenario where I have two applications with separate business logic to run on their triggers, on the same object? – Renato Oliveira Nov 12 '19 at 17:12
  • 1
    @RenatoOliveira if you are developing managed packages it is indeed best to keep the logic apart from each other, you do not want to bring out a package with a billion dependencies. But when you write code in an org(SF apps are a part of an org), it is still recommended to only have one trigger. – Novarg Nov 13 '19 at 8:37

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.