How to prevent a subflow from running

[Hari S1]

Hi,

I have a subflow in Flow Designer that gets triggered on record updates. If the subflow is already running and triggers it again, a new execution starts, causing multiple parallel runs.

Thanks

[RadhaK432361738]

ServiceNow Flow Designer does not support native execution locking for flows or subflows.
The recommended best-practice is to implement an explicit execution lock using data, typically via a record-level flag or status field.

At the start of the subflow, check a Boolean or state field (for example, Running).
If it’s already set, exit the subflow immediately.
If not, set the flag before any Wait action, allow the flow to run, and clear the flag when execution completes or fails (using an “Always” or error-handling path).

This approach reliably prevents parallel executions, works seamlessly with Wait actions, and is upgrade-safe and easy to maintain

[RadhaK432361738]

ServiceNow Flow Designer does not support native execution locking for flows or subflows.
The recommended best practice is to implement an explicit execution lock using data, typically via a record-level flag or status field.

At the start of the subflow, check a Boolean or state field (for example, Running).
If it’s already set, exit the subflow immediately.
If not, set the flag before any Wait action, allow the flow to run, and clear the flag when execution completes or fails (using an Always or error-handling path).

This approach reliably prevents parallel executions, works seamlessly with Wait actions, and is upgrade-safe and easy to maintain.

[RadhaK432361738]

Here is the same content without HTML and without any highlighting, plain text only:

ServiceNow Flow Designer does not support native execution locking for flows or subflows.
The recommended best practice is to implement an explicit execution lock using data, typically via a record-level flag or status field.

At the start of the subflow, check a Boolean or state field (for example, Running).
If it’s already set, exit the subflow immediately.
If not, set the flag before any Wait action, allow the flow to run, and clear the flag when execution completes or fails (using an Always or error-handling path).

This approach reliably prevents parallel executions, works seamlessly with Wait actions, and is upgrade-safe and easy to maintain.

[AdilakshmiA]

Hi @Hari S1 ,

The most straightforward approach is to use the "Only if not currently running" trigger condition for the primary flow (if it is triggered by a record update) or implement a lock mechanism within the flow using a custom action or a business rule with a unique field. 

Option 1: Configure the Flow Trigger (Recommended for Record Triggers) 

If the main flow that calls the subflow is triggered by a record update, you can use the built-in configuration option to manage concurrency for that specific record:

Open the flow in Flow Designer and select the Trigger section.
In the Run Trigger field (found under the Advanced Options section for Update or Created or Updated triggers), select "Only if not currently running".
This ensures that if another update occurs while the flow is running (or waiting) for the same record, the new trigger request is ignored, and the flow proceeds only after the current execution for that record is complete. 

Option 2: Implement a Lock Mechanism (For complex scenarios/generic subflows) 
For more complex scenarios where the above trigger option isn't sufficient (e.g., the subflow is generic and not tied to a single record's trigger, or is called from a script), you can use a locking mechanism:
Create a "Lock" Field: Add a custom boolean field (e.g., u_is_processing) to the table associated with the record that the flow operates on.
Check the Lock in the Flow: At the beginning of the main flow (before calling the subflow), add a condition or a Script step to check if the u_is_processing field is already set to true.
If it is true, the flow should end (using the End flow logic action).
If it is false, the flow proceeds and immediately sets the field to true.
Unlock on Completion/Error: Use the Flow Error Handler logic to ensure the lock field is set back to false when the flow finishes, whether it succeeds or encounters an error. This prevents the record from remaining permanently locked.
By utilizing these methods, you can effectively manage concurrent executions and prevent multiple instances of your subflow from running simultaneously for the same process.

please mark this complete if it answers your question

Thank you,
Adilakshmi