Skip to main content
A workflow automates a reaction to your data: a trigger plus a chain of actions, executed by the data platform. This reference documents the full model. For the user-facing guide, see Tags & automation → Workflows.

Flow definition

A workflow stores a flowDefinition: a graph of nodes and edges.
{
  "nodes": [ { "id": "…", "type": "trigger", "position": { "x": 0, "y": 0 }, "data": { /* node data */ } } ],
  "edges": [ { "id": "…", "source": "<node id>", "target": "<node id>" } ]
}
ElementShape
Node{ id, type, position: { x, y }, data }data.nodeType is the authority (TRIGGER or ACTION).
Edge{ id, source, target } — connects node ids, defining execution order.
Node data is a discriminated union by nodeType / actionType:
  • TriggernodeType: "TRIGGER" → see Triggers.
  • ActionnodeType: "ACTION" with an actionType of CREATE_OR_GET_PLAN, ADD_ITEMS_TO_PLAN, CALL_WEBHOOK, or SEND_EMAIL → see Actions and Integrations.

Workflow record

FieldMeaning
nameDisplay name (required).
descriptionOptional.
statusDRAFT · ACTIVE · PAUSED · ARCHIVED.
flowDefinitionThe nodes + edges graph.

Status

DRAFT → ACTIVE ⇄ PAUSED → ARCHIVED
  • DRAFT — editable, not triggerable.
  • ACTIVE — triggerable; only active workflows execute.
  • PAUSED — temporarily not accepting new runs.
  • ARCHIVED — historical.

Execution model

A run starts from the trigger (which resolves the matched entities), then follows the edges through the action nodes in order. Each node becomes a step with its own status, resolved inputs, and output — and a node’s output can feed later nodes via interpolation. See Runs & examples.

Validation rules

The builder enforces a few invariants:
  • Exactly one trigger node per workflow.
  • An ADD_ITEMS_TO_PLAN node’s planType must match the CREATE_OR_GET_PLAN it references via sourcePlanNodeId.
  • sourcePlanNodeId must point at an existing create-plan node.
  • No circular edges.
  • Discount percentages are bounded to [0, 100].