Workflows

A workflow chains tasks into a single run. Define the steps once, and Deck runs them in order, passes each step’s output to the next, skips steps whose conditions aren’t met, and loops over lists. You track one run instead of orchestrating a sequence of task runs from your server.

​

How workflows fit in

A workflow is an ordered list of steps. Each step references a task by task_id, and running the workflow turns every step into a full task run. A workflow can span more than one agent and more than one source, so one step can pull data from a hotel site and a later step can act on it in your expense platform. Running a workflow creates a workflow run (wrun_ prefix) that tracks every step, the task runs they produced, and the overall outcome. Each task run inside it is a normal task run with the same lifecycle, statuses, artifacts, and events. Manage workflows through the API, or from the Console, which offers autocomplete against upstream output schemas while you author steps.

​

Steps

A step is the unit of work inside a workflow: a task invocation, or a loop over one. Every step has a unique lowercase name, which is how later steps reference its output and how you target it with run-time values. Deck executes steps one at a time, top to bottom. Nothing runs in parallel, including inside a loop. Sequential execution is what lets a run reuse one session across steps, so an agent that logged in during one step stays logged in for the next. Later steps reference earlier outputs with {{ steps.<name>.output.<field> }} inside their input. Data moves through the workflow without a round trip to your server. Any step can carry an if condition that skips it when the condition is false.

​

Step types

​

Workflow run statuses

Once a run finishes, its result reports the outcome: success, failure, or unknown. A run only counts as success when every task run it produced succeeded.

​

Failure behavior

A workflow stops on the first step failure. Steps that already completed keep their output, steps that were never reached stay queued, and the error is recorded on the run with the name of the step that caused it. A for_each step can opt to keep going past a failed item so the rest of the list still gets processed. Every step in the run reports its own status, so one fetch shows which steps ran, which failed, and which were skipped by an if condition.

​

When to use workflows

If you’re chaining task runs, polling for completion, and deciding what to run next on your server, that’s a workflow. Define it once and let Deck run it. If you only need a single task, call the task run endpoint directly. If you need the chain to run on a schedule across many credentials, point a trigger at it.

​

Deep dives