<fork>

<fork> starts concurrent <branch> lanes that remain sequential internally and can use explicit join behavior.

Why use it

Use it when each concurrent lane needs more than one step or contains its own choices, parallel groups, or approvals.

Common use cases

• Prepare and publish content to several channels.
• Run independent multi-step processing lanes.
• Release the main continuation after selected branches while other branches finish.

Syntax

<fork id="distribution" join="instagram facebook">
  <branch id="instagram">
    <step id="prepareInstagram"><script>return prepareInstagram();</script></step>
    <step id="publishInstagram"><script>return publishInstagram();</script></step>
  </branch>
  <branch id="facebook">
    <step id="publishFacebook"><script>return publishFacebook();</script></step>
  </branch>
</fork>

Rules and behavior

• id is required.
• join is all, none, or a whitespace-separated list of branch IDs; omission means all.
• Branches see pre-fork context and earlier outputs in the same branch, never sibling output.
• Only joined branch outputs become visible to the main continuation.
• The workflow does not report success until every fork-owned branch settles.
• Nested forks inside a fork-owned branch subtree are rejected in v1.

Related documentation

• Forks and branches
• The parallel tag