---
title: Workflows
description: A saved recipe of steps and models. Attached at the gate, it lets a run go from packet to filed documents with nobody present.
section: Concepts
order: 2
---

A workflow is a named, versioned recipe: which steps a run performs and which model each step uses. Workflows are built under **Workflows** in the app. One of them is the organization's default.

## Steps

| Step | What it does |
| --- | --- |
| Preview | A cheap first pass that proposes where the documents in the packet begin and end. Optional. |
| Parse | Reads the pages in full. Required. |
| Classify | Composes the read pages into documents, names them, and matches them to the expected document list. |
| Judge | An independent second opinion on each document, with a confidence. |
| Extract | Pulls field values using the [document schema](/docs/concepts/document-schemas) for each document type. |

Steps run in order. There is no branching, on purpose.

## Versions

Like lists, a workflow version is a **draft** until activated and **frozen** once active. Only an active version can run. Publishing a new version changes what the workflow does without changing its id, so whoever calls it keeps calling the same thing.

## What attaching a workflow means

Taking the gate with a workflow attached is a single consent for the whole chain. When the run lands, the workflow files and approves everything it recommended, and the ledger records those decisions as made by **Workflow**, under the identity of whoever took the gate.

What it will not do: override red flags at the gate, reject a document, or delete anything. Those stay with a person. Anything the workflow was unsure of is left unfiled in Triage.

## Over the API

`GET /workflows` lists your workflows and their versions. Each one is addressable by id the moment it has an active version: see [run a workflow](/docs/api/run-a-workflow).