0

I'm working on a project that needs to evaluate that uses a trigger which will check the object against a bunch of rules criteria to see if the data meets some conditions that the user can configure.

We are using after update/insert triggers so that it works well with other triggers however, it appears that our trigger goes off multiple times when a workflow is used instead. This causes weird issues where at one point the data could meet the rule criteria at one point but then the workflow will update it so it no longer does. Additionally, it is wasted computational time to be evaluating the object before all the workflows have completed. Is there a way to wait until all workflows and other automation has completed before evaluating wether our the object meets our rule criteria?

3
  • 1
    Short answer is no, there is no finalizer available to general transactions. It is still only Pilot for Queueables.
    – Adrian Larson
    Commented Apr 9, 2020 at 22:13
  • You should move all your logic to trigger no field update on workflow or process builder should be there with field update if you want to handle it . You can check change data capture if that helps. Commented Apr 10, 2020 at 0:59
  • Can't do that, if it passes the criteria we make an insert into a different table.
    – J. Larson
    Commented Apr 10, 2020 at 22:49

1 Answer 1

1

The not-so-fun answer (besides "no", which is accurate) is that you need to refactor your automation to get back to a position where the save order isn't causing you problems and is congruent with your business' expectations about the structure and integrity of your data.

While you can build your triggers to be resilient against recursion caused by workflow updates, what you can't do is control the save order itself or change your position in it. Since your business requirements expect your triggers to react to record states that are destroyed as a consequence of Workflow Rules, you're in a position where data integrity is very difficult to guarantee. That indicates that your automation is not well-structured for your needs.

Consider refactoring your Workflow Rules into either before insert/before update trigger handler classes, where you can control the order of what's executed, or before-save flows, which run prior to triggers, don't have recursion problems, and can help you guarantee data consistency through the order of execution.

3
  • Would I be able to do something like add their IDs to a set in an instance of a batchable or queable class? Would I be able to guarantee that the queable or batchable instance doesn't start until after workflows are done executing or would they just kick off new asynchronous tasks for each workflow update?
    – J. Larson
    Commented Apr 13, 2020 at 16:57
  • You could, but then it's not transactional.The batch or Queueable won't begin executing until some time after the transaction commits, meaning any updates they perform will be asynchronous.
    – David Reed
    Commented Apr 13, 2020 at 17:03
  • That's fine in my use case. The update it performs is to basically create an item in another queue which will export the data to another system, so it shouldn't be an issue if that's not in the transaction.
    – J. Larson
    Commented Apr 13, 2020 at 17:22

You must log in to answer this question.

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