Workflows are in preview and not yet available in the product.
Move multi-step orchestration off your server and into Deck. Instead of polling for results, parsing output, deciding what to do next, and firing off another request, define the entire sequence as a workflow. Deck runs it end-to-end with built-in branching, looping, and failure recovery. No queues to wire. No schedulers to tune.
How workflows fit in
Workflows coordinate tasks across one or more agents. Each step specifies an agent and task. When you run a workflow, you pass a connection for each agent involved, and Deck handles the rest. A single workflow can pull data from one source and act on it in another.
Step types
| Type | What it does |
|---|
| Task | Runs a task using the connection mapped to its agent |
| Branch | Evaluates a condition and runs then or else steps |
| Sleep | Pauses for a specified duration |
Steps execute in order. Output from earlier steps flows into later steps using {{ }} templating, so data moves through the workflow without round-trips to your server.
Workflow run statuses
When you run a workflow, Deck creates a workflow run (wrun_) that tracks every step.
| Status | Meaning |
|---|
queued | Waiting to start |
running | Executing a step |
sleeping | Paused between steps |
interaction_required | A step needs user input |
completed | All steps finished |
failed | A step failed and the workflow stopped |
canceled | You canceled the workflow |
Failure behavior
| Option | What happens |
|---|
stop | The workflow fails immediately (default) |
continue | Skip the failed step and continue. Dependents are also skipped. |
retry | Retry the failed step before stopping |
When to use workflows
If you’re chaining API calls, polling for completion, or writing retry logic on your server, that’s a workflow. Define it once, and let Deck handle the rest. If you only need a single task, use the task run endpoint directly.
Deep dives