0

Can a Trigger Handler be used on 2 separate Triggers, so that if 1 trigger processing the data onto another object, and then the other trigger is prevented by the handler, and vice versa when the data is coming from the other direction.

Ultimate Challenge: to sync 2 similar objects to keep them up to date in either direction. Using triggers so that they update in realtime. Using a Trigger Handler to prevent recursion.

Role__c object with these fields:

  • Contact__c (Id)
  • Account__c (Id)
  • Type__c (text)
  • Association__c (Id) link to other object

Association__c object with these fields:

  • Contact__c (Id)
  • Account__c (Id)
  • Type__c (text)
  • Role__c (Id)

The question is can I instantiate a Handler & its boolean hasRunOnce on 1 trigger, so that the other trigger can see it and not process? - preventing recursion.

(below-non functioning Pseudo Code if you can call it that)

Role Trigger (After Insert, After Update){
    if(!Handler.hasRunOnce){
        Handler.hasRunOnce = true;
        Process Data onto the Association Object
    }
}

Association Trigger (After Insert, After Update){
    if(Handler.hasRunOnce){
        Handler.hasRunOnce = true;
        Process Data onto the Role Object
    }
}

I know of a way to pass a boolean in the 2nd object, and use the before trigger to manage boolean's state and set the handler variable in the before and then prevent the after from running the reverse sync(and prevent recusion).

But the premise of this question is to ask if a handler can communicate across triggers of different objects?

1 Answer 1

2

Yes. Static variables are accessible anywhere throughout the transaction, even in totally different objects, as long as it is the same transaction. Keep in mind that you want to reset the flag if you're only concerned about recursive access. There are plenty of reasons you'd want your trigger to run more than once in a transaction, including unit tests, partial saves, workflow/process builder/flow updates, and lists of more than 200 records. Do not forget to reset the flag, because you will cause problems for someone in the future.

Even better, as I recommend in my other answer, don't block recursion. Instead, perform "lazy" updates; in other words, check to see if the record you intend to update has actually changed, and if not, don't perform another DML. For example, if you have Account and Contact triggers, and they push changes to the Phone field to the other, have each make sure that the phone number doesn't match before trying to update. In this case, if the Account goes first, the Contact will be updated, then see the Account doesn't need to update. On the other hand, if the Contact goes first, the Account will be updated, and the Account will see that that Contact doesn't need to be updated (but, other Contacts may be updated). In this fashion, the recursion is self-limiting without using any actual recursion blocking flags.

1
  • Nice Options, definitely like the later, smart,and only the requires the logic that is already contained in the requirement. my alternate solution above using a boolean on before is now also way over engineered, so thank you. Thank you, plenty of options. Jan 20, 2022 at 2:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .