Workflows & state machines

• State — a named position in the workflow (Draft, Submitted, Approved, Rejected, Closed).
• Transition — a named move between states (Submit, Approve, Reject, Reopen).
• Guard — a predicate that must hold for a transition to be allowed.
• Effect — a side-effect that fires when a transition succeeds (notification, webhook, new record).

states: [draft, submitted, investigating, closed, reopened]
initial: draft
transitions:
  submit:   { from: draft,         to: submitted,     requires: [severity, description] }
  open:     { from: submitted,     to: investigating, roles:    [incident-reviewer] }
  close:    { from: investigating, to: closed,        roles:    [incident-reviewer], requires: [rca_text, capa_created] }
  reopen:   { from: closed,        to: reopened,      roles:    [incident-admin] }

• requires — specific fields must be non-null before the transition is allowed.
• roles — only users with these roles see the transition button.
• when — a boolean expression over record fields (e.g. severity >= 3).
• approvers — N approvers (with role filter) must approve before the transition fires.

• notify — send a notification to a user, role, or @-mentioned person.
• webhook — fire an HTTPS POST to a tenant-registered endpoint (see Dev portal → Webhooks).
• create-record — spawn a subrecord (e.g. auto-create a CAPA on incident close).
• run-automation — invoke a named automation (for more complex branching).

Publishing a workflow change creates a new version. Existing records stay on their original version until you migrate them. The Composer shows the diff and gates publishing behind an admin confirmation.