0

We have the following:

  1. an record-triggered after-save flow on Opp, which depending on circumstances may do several DMLs, including an update to the triggering opp.
  2. a PB op Opp which calls a separate autolaunched flow that sends an email

One of the updates that #1 does to the triggering opp is a field change that would cause the opp to meet the conditions for #2. So what we'd expect is for both of them to run.

However, the behavior we're seeing is that when #1 runs, #2 does not run. It's not that the #2 PB is firing and not meeting the conditions. Based on debug logs, it's not firing at all. And we don't understand why.

We know about the recursion prevention features outlined here https://architect.salesforce.com/design/decision-guides/trigger-automation/ but those wouldn't seem to apply here. The key sentence seems to be this:

If that trigger has already previously fired in response to a previous DML operation ... and in doing so set off a chain of DML operations that has led to the current DML ... The trigger doesn't fire.

In our case the PB in #2 is firing before the flow in #1. But it's not meeting its conditions (since flow #1 hasn't set that field yet) so it does nothing. So while the PB in #2 "previously fired" it didn't "set off a chain of DML operations...". Am I misunderstanding this?

If not, can anyone think of other reasons why #2 would not be firing after #1 does its update?

BTW, we do understand that in most cases it's better to handle field updates on the triggering record in a before-save flow or trigger. But in this case the #1 flow is updating additional records, not just the triggering opp.

TIA for your help!

EDIT: we got this working already by changing how these flows are triggered. But we would still like to understand why it was behaving the way it was originally.

Improve this question
2
  • Is it not the case that the flow's update to the opp is not re-evaluated so the PB is not executed? Why not build this PB into the flow?
    – Phil W
    Commented Aug 24, 2021 at 6:31
  • Well, why wouldn't it be re-evaluated? My understanding is that DMLs in an after trigger do in general trigger other automation, except in the case outlined in the article I quoted above, which doesn't seem to apply here. So while it certainly seems like it's not being re-evaluated, I would like to know why so I can better understand how this works.
    – mscholtz
    Commented Aug 25, 2021 at 21:40

1 Answer 1

Reset to default
1

According to the order of execution (see this link: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm) processes and flows runs in the same step between before triggered flows and after triggered flows, so your Process Builder (2) is running before your after trigger Flow (1).

I suggest changing the after trigger Flow to a before trigger Flow or moving your after trigger Flow's actions to a Apex Trigger on After Insert/Update

Improve this answer
1
  • Thanks! We actually already got it working, using an approach similar to this. At this point we just want to understand why it was behaving the way it was. I will update the original post to reflect that.
    – mscholtz
    Commented Aug 25, 2021 at 22:57

You must log in to answer this question.

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