Latch

The Latch node is a countdown latch for coordinating parallel work. It lets one part of an automation wait until a specified number of other tasks have finished — the classic fan-out-then-continue pattern. You create a latch with a starting count, each parallel task decrements it when done, and the step that waits on the latch resumes only when the count reaches zero.

Use it to kick off several branches or sub-automations in parallel, gate a downstream step on all of them completing, and handle cases where some tasks may not finish in time.

Operations

Create Latch

Initializes a new latch with a starting count equal to the number of parallel tasks you are waiting on. You must create the latch before any task tries to count it down or wait on it — referencing a latch that does not exist yet will fail.

Input

Output

Returns the latch ID and its initial count, confirming the latch is ready for use.

Count Down

Decrements the latch's count by a specified amount (default: 1). Call this from each parallel task when it completes its work. When the count reaches zero, any step waiting on the latch is released to continue.

Input

Wait For Latch

Suspends the current execution until the latch count reaches zero. The wait is asynchronous — the run pauses without holding runtime resources, so other work can proceed. Once the latch hits zero, the waiting step resumes and continues the automation.

Input

Output

Returns when the latch reaches zero or the timeout elapses. The output includes a flag indicating whether the step resumed because the count reached zero or because the timeout expired.

Coordination Pattern

The correct order of operations is:

1. Create Latch — before spawning the parallel tasks, with a count matching how many tasks you are waiting on.

2. Start parallel tasks — each task receives the latch ID and calls Count Down when it finishes.

3. Wait For Latch — the step that should continue only after all tasks complete waits on the latch.

Note: Each latch is scoped to its own automation run. The same latch ID in two different runs refers to two independent latches and they do not interfere with each other.

Timeouts and Persistence

If you need to handle the case where not all parallel tasks finish within an acceptable window, set a Timeout on the Wait For Latch step. When the timeout elapses the waiter resumes with a timeout flag, giving you a branch to handle partial completion — log a warning, skip remaining work, or alert on the incomplete tasks.

By default, latch state lives in memory for the duration of the run. For long-running coordination that must survive a service restart — for example, waiting on tasks that could take hours — enable the Persist option on the Wait For Latch step. This durably saves the waiting state so it can resume on another runtime instance if needed.

Notes

To make the most of it:

• Always create the latch before spawning the tasks that will count it down — a count-down or wait on a non-existent latch fails immediately.

• Set the starting count precisely to the number of tasks that will call Count Down; under-counting releases the waiter too early, over-counting leaves it waiting indefinitely.

• Always configure a Timeout on Wait For Latch in production automations so a stalled or failed parallel task cannot block the automation forever.

• Check the timeout flag in the step following Wait For Latch to distinguish between "all tasks completed" and "timeout expired" before continuing downstream logic.

• Enable Persist only when coordination spans long durations or infrastructure events; for quick in-run fan-in the overhead of persistence is unnecessary.