Following my previous question regarding order of execution. I recently, started more experiments to understand it even better.

I have seperated this into 3 sections, Context, Preface For Main Question, The Main Question.

So here, let's say I have a custom object named: Object D
Now, if I have a before save flow (fast field), that runs on creation, in Object D to look something like this: enter image description here

When I try to create a new record of object D, the name will be 'Name is Before Flow'. This is because, I believe from the order of execution architecture diagram, we can see that before save flow runs first. Hence changing the record's name before making a 'save' (not commit) and when the process goes on, it will finally commit this record to the database.

Preface For Main Question:
Hence, in my another experiment I have a custom object called Object C.

I made 2 after save flows, as can be viewed below: Flow 1
Flow 2

My First Question: To aid my understanding, when a after save flow is executed to update the triggering record, then the entire OOExecution is fired again right (from step 1) this time with the new field values as stated in the update element and it will skip all the flows that it has already run?

That is my understanding, that's why in this experiment it actually succeeded because I believe, when the first flow executed and updated the name to 'From Flow Number 1' then, with this new value, it executed another OOE from step 1, in this context, it will have all the new values and will skip Flow 1 because it has already run the flow? (I found this article in SFBen)

enter image description here

and this time, it will run Flow 2, which check's if the name is 'Flow From Number 1' and it will be true and hence update the Name to 'From Flow 2' and start another OOExecution and this time around no flows will run since both the flows has already run once, in this transaction?

The Main Question
Now lies, the main question, if all the above conclusion were true. I created another before save (fast field) flow for Object C.

The 3 flows are as below:

  1. Flow 1 (After Save Flow) (Entry criteria: When Record's name is changed)
  2. Flow 2 (Before Save Flow) (Entry criteria: When Record's counter = 1)
  3. Flow 3 (After Save Flow) (No entry criteria, whenever record is updated)

enter image description here enter image description here enter image description here

Technically, when I make a change in Object C record this should be the order right

Flow 1 (After Save) -> Flow 2 (Before Save) -> Flow 3 (After Save)

Flow 2 will run after Flow 1 because:

  1. Firstly, counter will be blank for new record. So when I update the name of this new record, flow 2 will get skipped first (because entry criteria not met) (entry criteria is counter = 1) and Flow 1 will run first (as the first after save).
  2. Flow 1 will update the record's counter (=1) and name, which will invoke another OOE.
  3. This new values will meet the entry condition for Flow 2 (counter = 1) and assignment will change the record's counter value to 2.
  4. Continue the path of this 2nd OOE, After save flow (Flow 3) will run, and at this point the record's counter should be 2 right?

Why is the counter value is equals to 1 in the Flow 3 instead of it being 2 (as assigned into the before save flow)?

Can anyone help me on understanding this please, many thanks for reading through this long explanations.

  • What's the actual question? What is being 1 instead of 2? You really need to break this down into 1 simple question because this wall of text is very hard to understand and there's no clear question at the end.
    – Nick C
    Commented Feb 20 at 4:37
  • @NickC, if you refer to the "The Main Question" section, that's where my question is, if you have a flow flows from After Save -> Before Save -> After Save. Then why isn't the final After Save flow, getting the right values from the Before Save flow? For example, you can see in Flow 2, I am changing the record's counter variable to 2, which is then supposed to flow into the Flow 3. However, in Flow 3, the counter variable is still equals to 1, instead of 2. Ignoring the changes made in Flow 2. Many thanks!
    – prem22
    Commented Feb 20 at 6:55
  • It's an interesting question, and I can't give you a good answer without personally running and analyzing debug logs to see what flow interviews are executing and in what order, but from a platform architecture and best practices perspective I'd argue that this type of flow design should be avoided. Before Save flows exist for a reason, and that reason is to avoid recursive saves/OOEs. Using After Save flows to update the triggering record is not good practice, that's why Before Save flows were introduced in the first place. Commented Feb 20 at 15:59
  • If you need multiple, separate flows to evaluate a record based on entry criteria and update that triggering record accordingly, then you should create multiple before save flows and use flow execution order to control the order of evaluation. After Save flows should be reserved for updates to non-triggering records. Commented Feb 20 at 16:01
  • @MorganMarchese Thanks alot for your time and input. Yes I built this flow mainly for experimental purpose to get a good grasp of OOE. To test my understanding I built these flows, but I could not understand why the before save flow value is not being passed into the after save flow?
    – prem22
    Commented Feb 21 at 14:46


You must log in to answer this question.

Browse other questions tagged .