Build a workflow

A Workflow is a defined execution path for recurring operational work.

Orient yourself in the editor

The centre of the editor is the canvas. Each action appears as a card, and the connecting line between cards shows the execution path. The Workflow selector and version indicator sit above the canvas.

Run, Feedback, Test and Publish are four tabs of the same right-hand lifecycle panel. Run executes the current Draft; Feedback records feedback on a run; Test opens the Workflow test panel, headed Evaluations in the current UI; Publish manages versions and live publication state.

A current Workflow editor with the canvas, header lifecycle tabs, validation state and bottom canvas controls visible.

The bottom canvas bar contains navigation and layout controls plus Add Action. The minimap is a separate floating panel when the Workflow extends beyond the current viewport.

Use the dedicated Canvas reference pages for those editor mechanics.

Design before you wire

Before placing actions, define:

• Trigger — what event creates the work?

• Outcome — what should be true when the Workflow is complete?

• Inputs — what information does it need, and which source is authoritative?

• Logic — which decisions can be encoded directly?

• Data flow — what must each step receive from earlier steps?

• Human boundary — where should execution stop and ask a person through a configured Request?

• Failure behaviour — should a failure stop, explicitly retry, or continue with an error state?

Read the visual path as execution

The canvas is not just a diagram. Connected actions represent the route the Workflow can execute. Keep the main path readable, use explicit flow-control actions where paths diverge, and avoid relying on layout alone to communicate business logic.

Descriptions on cards help explain what each step is intended to do. The underlying configuration and data bindings are what determine execution.

Test with production consequences in mind

When the draft is ready, use Run or the Test surface to exercise it. These are real Workflow executions and can call external systems, send messages or make writes. They are not automatically side-effect-free sandboxes.

When behaviour is correct, use Test and publish to understand Draft → Published behaviour and the live active/default path.