1

Our Salesforce org depends on about 20 managed packages, many of which include their own SObjects, and many of those SObjects have their own trigger operations.

But we also need to do our own things with them, things which for a variety of reasons we want/need to do with triggers.

Unfortunately, SFDC does not offer us any native way to specify a sort order for trigger operations.

Even more vexing, neither do the third party vendors give us any way to inject our solutions into their trigger processes.

So, I'm wondering if there are any third party solutions / hacks which will allow us to control the order of operations?

Alternatively, if it is impossible to take complete control, what might be the pros and cons of using the Trigger just to launch an asynchronous event so we could guarantee our operation is last? Could we actually somehow guarantee at least that? Or could we find ourselves facing race conditions? And would there be any recommended solutions to avoid recursion / circular logic?

Improve this question

2 Answers 2

Reset to default
2

The official documentation does state that there is no way to control order of execution for triggers:

The order of execution isn’t guaranteed when having multiple triggers for the same object due to the same event. For example, if you have two before insert triggers for Case, and a new Case record is inserted that fires the two triggers, the order in which these triggers fire isn’t guaranteed.

Since you want to execute some processing after all triggers are done, as long as you are happy to do that in the "after" phase, the saving grace is:

  1. Executes processes and flows launched via processes and flow trigger workflow actions

Since this is after all the triggers have run.

Improve this answer
3
  • I'm not 100% clear on what you are suggesting. Do you mean we could set up a PB/flow which will reliably execute Apex code after everything else?
    – Brian Kessler
    Apr 29, 2019 at 13:57
  • 1
    @BrianKessler, yes, I am. Take a look at the cited documentation to get a clear picture as to the processing sequence. Note that if you update the record in your process builder flow then all the triggers will be re-executed of course.
    – Phil W
    Apr 29, 2019 at 15:01
  • We'd prefer to keep PB out of the mix, but I'm upvoting the proposed solution... I'd prefer to wait a little to see if any other solutions are offered before accepting it (but I'll eventually do that if/when it becomes clear that no other solutions are possible or everything else seems like a nasty hack)
    – Brian Kessler
    Apr 30, 2019 at 14:26
0

Because workflows are always executed after triggers, one could use a workflow doing nothing more than incrementing a (hidden) number field (called Changed__c with a workflow formula similar to IF(ISBLANK(Changed__c), 0, Changed__c +1)).

Your trigger would only fire when this field is changed (kind of oldTrigger.Changed__c != newTrigger.Changed__c). This would ensure the "normal" triggers to have fired at least once.

Improve this answer

You must log in to answer this question.

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