I'm relatively new to my current company and am working through an audit of all of our flows. Upon testing, I am realizing that for all flows, when a Flow is set to run when A record is created or updated, and if you use FieldA IsChanged=True as part of your Entry Criteria for the flow, it will never run on creation, even though FieldA is going from Null to ValueA. The only workaround I've found is using a Formula as the entry criteria where RecordPrior.FieldA <> Record.FieldA or RecordPrior.FieldA == Null && Record.FieldA <> Null

Am I missing something here? This appears to be a pretty serious bug or oversight on Salesforce's end, but I want to make sure this isn't something I might be overlooking on my end before I either raise the flag with Salesforce and/or spend several days rewriting/retesting our flows.

enter image description here

5 Answers 5


From the doc:

The Is Changed operator is available for flows that are triggered when a record is updated. The Is Changed operator isn’t available for flows that are triggered when a record is created or deleted.

When the record is created, the value doesn't change because no previous value exists. Thus Is Changed won't evaluate.

The formula-based approach you've outlined is the current best practice for working around this in a 'create or update' trigger.

Is Changed implementation is a classic trade-off where no solution is perfect. Having separate flows for create vs update is already possible yet many prefer having these two triggers in one flow. When you select created or updated, should Flow Builder put up a warning that Is Changed doesn't apply to update? Possible but doing so would set a precedent and corresponding expectation for all other scenarios that may deserve a warning. Plus, it's already a busy screen.

Nevertheless, we agree with you that this UX can be improved. Feel free to create an idea on IdeaExchange and get 10,000 or so other users to upvote it, then something might happen. You have our vote.

  • Thanks a ton! I searched for about 30 minutes and couldn't find anything. That link mixed with your input is exactly what I was hoping for.
    – Jake
    Commented Aug 2, 2022 at 23:37

I struggled with testing this in many flows. I was able to utilize a ISNEW() in my entry criteria. Then I used a split decision that if ISNEW() = True, then go down the new path for (Create/Update Flow). However, if ISNEW() = False, then go down the update path.

I agree, this could be improved however I figured i'd share as this made my life a bit easier working through the flows and wondering why they were not firing in certain scenarios.


I found out that we can use $Record_Prior = null to check is is a new record or not.


Thank you for this conversation! I used your suggestion, Jake, and tweaked the formula because I could not get it to work. Not sure if ISNEW() function was available when this was originally posted, but I've tested and this works when I select a record is created or updated and criteria formula evaluates to true:



It's working as expected as per the following:

This function returns FALSE when evaluating any field on a newly created record.

Reference: ISCHANGED

PRIORVALUE() evaluates to the following when a new record is created:

When users create a record, this function returns the value of the field referenced rather than null. For example, if you create an account named "Acme," PRIORVALUE(Account.Name) returns Acme.


Hence the ISCHANGED() returns false

You must log in to answer this question.

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