<workflow>

<workflow> defines one runnable automation. Its identity binds triggers, policy, business steps, lifecycle hooks, and immutable run definitions.

Why use it

Use it as the execution boundary for work that needs durable admission, state, retries, recovery, and operator control.

Common use cases

• Run a trigger-driven automation.
• Create a call-only child workflow by omitting triggers.
• Activate several workflows together as one deployment.

Syntax

<workflow id="process-order" name="Process order" version="1.0.0">
  <triggers>...</triggers>
  <steps>...</steps>
</workflow>

Rules and behavior

• id is required and uses lowercase kebab-case.
• name, description, and author-owned version are optional.
• It contains exactly one <steps> and optional singleton <config>, <lifecycle>, and <triggers> children.
• The four workflow children may appear in any source order.
• Runtime policy belongs in <config>; workflow-level timeout and concurrency attributes are invalid.

Related documentation

• Workflow structure
• Runtime configuration