1

Flow decision elements have multiple ways to control when to run a particular path. I frequently have requirements which look like "when this application step is completed, move the Application to the next step". Now from what I can see, there are 2 different ways to do this.

Option 1: Use logic in the Decision Outcome like "Field__c IS CHANGED = TRUE"

Option 2: Update the "When to Execute Outcome" setting to "Only if the record that triggered the flow to run is updated to meet the condition requirements".

enter image description here

These 2 options do the same thing as far as I can tell, so is there a best practice about when to use the IS CHANGED operator vs. the "When to Execute Outcome" setting? Is one more stable/reliable/efficient than the other? Or are they completely interchangeable?

I've noticed that when using the IS CHANGED operator, Flow does not always run as predictably/reliably as I would like, especially if an external system/integration is updating the record. In some scenarios, maybe due to apex firing first and updating other fields, if an external system updates the record it sometimes doesn't see the field in question as having been "changed".

Improve this question
3
  • Sounds like you need to read Well Architected: Automation. Search for "Flow also provides entry conditions" and read that piece. It is all about performance and best to put this in the flow entry condition itself, if possible.
    – Phil W
    Commented Nov 20, 2023 at 7:14
  • @PhilW I have read through that article. I understand entry criteria are best for performance, but that wasn't really my question. My question was, is there a best practice for using IS CHANGED vs the "When to Execute Outcome" setting. Both of those are options in the entry criteria AND decision elements, so my question still stands. Is there any difference in how these are evaluated and/or best practices for using one or the other?
    – JustinF
    Commented Nov 20, 2023 at 9:09
  • I realize that I didn't answer the question, but thought it worth drawing attention to an alternative way to handle the type of condition you have (obviously assuming there wasn't further context that means the condition cannot be on entry).
    – Phil W
    Commented Nov 20, 2023 at 9:43

1 Answer 1

Reset to default
3

In your specific case, considering only the one field's value, there is essentially no difference.

However, there are differences between the two options if your condition includes multiple different fields (or where the condition doesn't (only) use record field values in the condition terms).

Consider a condition with fields A and B. If you want the logic:

IF B has changed to 1 AND A is 2 THEN

it makes sense to use ISCHANGED against B. Using the "if updated to meet condition" approach and without an ISCHANGED effectively results in:

IF B or A has changed AND B is 1 AND A is 2

Why? Because "if updated to meet condition" can be thought of as: 1. a check of the condition with the old data for the record, then if that is false, 2. a check of the condition with the new record data. At the end of 2, if the condition is met with the new data, we know the record was updated to meet the condition (because it didn't meet before).

If the condition is using non-record data (e.g. variables in the flow returned from invocable apex or similar) then clearly you cannot use ISCHANGED against such a value, and the "if updated to meet condition" option cannot consider a change in that value. However, you can still use the ISCHANGED or "if update to meet condition" approaches on any fields that are used as part of the condition, I believe.

Improve this answer
1
  • Thanks so much, this makes sense!
    – JustinF
    Commented Nov 20, 2023 at 15:45

You must log in to answer this question.

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