> ## Documentation Index
> Fetch the complete documentation index at: https://docs.deck.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Workflows

> Chain tasks into a single execution with conditions, loops, and shared sessions.

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](/concepts/tasks) by `task_id`, and running the workflow turns every step into a full [task run](/concepts/task-runs). 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](/events/events). Manage workflows through the API, or from the [Console](https://console.deck.co), 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

| Type       | What it does                                                            |
| ---------- | ----------------------------------------------------------------------- |
| `task`     | Runs a task as a task run, with an optional credential or public source |
| `for_each` | Runs an inner task step once per item in an array from an earlier step  |

## Workflow run statuses

| Status      | Meaning                                                                                                         |
| ----------- | --------------------------------------------------------------------------------------------------------------- |
| `queued`    | Waiting to start                                                                                                |
| `running`   | Executing a step                                                                                                |
| `paused`    | The current step is waiting on external input, such as MFA or review. The step's own status carries the reason. |
| `completed` | All steps finished                                                                                              |
| `failed`    | A step failed and the workflow stopped                                                                          |
| `canceling` | Cancellation requested, the current step is stopping                                                            |
| `canceled`  | You canceled the workflow before it completed                                                                   |

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](/concepts/task-runs) endpoint directly. If you need the chain to run on a schedule across many credentials, point a [trigger](/concepts/triggers) at it.

## Deep dives

<CardGroup cols={2}>
  <Card title="Build a workflow" icon="diagram-project" href="/guides/workflows">
    Full examples with output references, conditions, loops, and failure handling.
  </Card>

  <Card title="Task runs" icon="play" href="/concepts/task-runs">
    The execution primitive every workflow step wraps.
  </Card>

  <Card title="Triggers" icon="clock" href="/concepts/triggers">
    Run a workflow on a schedule, fanned out across credentials.
  </Card>

  <Card title="Events" icon="bolt" href="/events/events">
    Subscribe to workflow lifecycle and workflow run events.
  </Card>
</CardGroup>
