Flow Designer: When an Action needs to be completed before proceeding to the next step

Chris176
Tera Contributor

Hi all,

 

A question around execution order more than anything. Without going in to specifics - if a particular record we expect to see does not exist on a table, we create one using the Create Record action in a flow. The next step would then set a Flow variable with that record's new values as well as some existing ones referencing them later in the flow.

 

Our issue here is that the flow fails as it is expecting the record to exist when it proceeds to the next step, yet it isn't yet there on the table. We have found this confusing as having to use a "wait for" action or anything of the sort to ensure the record is created, let alone updated, seems to be illogical.

 

Is this requirement for waits in the flow the expected behaviour?

1 ACCEPTED SOLUTION

Hello @DanC123 

The Create Record action in ServiceNow Flow Designer is asynchronous by default. This means that while the flow triggers the creation of a record, the actual database commit may not be completed before the next step in the flow executes. This can lead to race conditions where subsequent actions (like setting variables or referencing the newly created record) fail because the record isn’t yet available in the database.

This behavior is not explicitly documented in the core product docs, but it is acknowledged by experts and in community best practices. A great reference is the ServiceNow Guru article on Sync/Async Patterns in Flow Designer, which explains how flows typically run in the background, outside of the business rule transaction loop, making them asynchronous unless explicitly configured otherwise.

If my response has helped you hit helpful button and if your concern is solved do mark my response as correct.

 

Thanks & Regards
Viraj Hudlikar.

View solution in original post

4 REPLIES 4

Viraj Hudlikar
Giga Sage

Hello @Chris176 

 

 

Create Record actions are asynchronous. Even though the action is triggered in the flow, the actual database commit may not be completed before the next action executes. So, when you set the Flow variable immediately afterward, it might reference a record that hasn’t yet fully materialized in the database, especially if there's logic dependent on field values or relationships.

 

Yes, it's generally best practice to introduce a Wait For Condition or a Wait Timer to:

  • Ensure the record is actually committed before referencing it.

  • Allow time for any additional business rules, workflow scripts, or updates to finish executing.

This might feel redundant, but in platform automation, especially in low-code environments like Flow Designer, execution order isn't guaranteed the same way it would be in a traditional synchronous script. So the "wait" acts as a safe gate to avoid race conditions.

 

If my response has helped you hit helpful button and if your concern is solved do mark my response as correct.

 

Thanks & Regards
Viraj Hudlikar.

 

Hi @Viraj Hudlikar 
Thanks for the explanation, but I've been unable to find more details on this and have issues with similar behaviour so hope you can help, as the options provided around wait timers or for conditions are not intuitive for a lot of users in a low code environment.

- How do you know the Create Record actions are asynchronous, is there no option to make them synchronous?
- What other actions are asynchronous, as the the expectation was that all of them were synchronous?

Finding some further reading on this from ServiceNow would be really useful.

Hello @DanC123 

The Create Record action in ServiceNow Flow Designer is asynchronous by default. This means that while the flow triggers the creation of a record, the actual database commit may not be completed before the next step in the flow executes. This can lead to race conditions where subsequent actions (like setting variables or referencing the newly created record) fail because the record isn’t yet available in the database.

This behavior is not explicitly documented in the core product docs, but it is acknowledged by experts and in community best practices. A great reference is the ServiceNow Guru article on Sync/Async Patterns in Flow Designer, which explains how flows typically run in the background, outside of the business rule transaction loop, making them asynchronous unless explicitly configured otherwise.

If my response has helped you hit helpful button and if your concern is solved do mark my response as correct.

 

Thanks & Regards
Viraj Hudlikar.

Hello @Chris176 

I believe you are doing great.

Did my reply answer your question?


If my response helped, please mark it correct and close the thread so that it benefits future readers.

 

Thanks & Regards
Viraj Hudlikar.