Parallel Execution

Use <parallel> for independent direct steps that should run concurrently and all rejoin.

Example

<parallel id="checks" concurrency="2" on-error="wait-all">
  <step id="inventory"><script>return checkInventory();</script></step>
  <step id="risk"><script>return checkRisk();</script></step>
</parallel>

The group requires id. Optional concurrency limits active children. on-error is fail-fast or wait-all and defaults to fail-fast.

Data rules

Every child sees the same context available before the group. Siblings cannot reference one another. Each child publishes its own context.steps.<id> output; the parallel group has no aggregate result.

Add a downstream step to combine sibling outputs. Use Forks and Branches when each concurrent lane needs multiple steps.

Build concurrent checks

<parallel
  id="orderChecks"
  name="Run order checks"
  description="Check stock and risk at the same time."
  concurrency="2"
  on-error="wait-all"
>
  <step id="stockCheck" name="Check stock">
    <script>
      return { available: context.payload.inStock };
    </script>
  </step>
  <step id="riskCheck" name="Check risk">
    <script>
      return { approved: context.payload.riskScore < 70 };
    </script>
  </step>
</parallel>

<step id="combineChecks" name="Combine checks">
  <script>
    return {
      accepted:
        context.steps.stockCheck.available &&
        context.steps.riskCheck.approved
    };
  </script>
</step>

Both children receive the context that existed before orderChecks. Neither can read the other's output because completion order is not deterministic. The downstream step runs after the group settles and can safely combine both results.

Control concurrency

concurrency limits simultaneously active children and cannot exceed the number of children. Omit it when every child may run together. Lower it when external capacity or local resource use requires a bound.

Choose an error policy

fail-fast stops unstarted children and requests cancellation of active children after one failure. wait-all lets every child settle so you can observe all outcomes. Both policies fail the group when any child fails.

Use wait-all for independent diagnostics or checks where complete information is valuable. Use fail-fast when additional work has no value after one required operation fails.

Cancellation is cooperative around external operations. Do not assume every remote side effect can be reversed because another sibling failed.