> For the complete documentation index, see [llms.txt](https://docs.unitlab.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.unitlab.ai/documentation/workflows/workflows-overview.md).

# Workflows overview

A Unitlab workflow is the operational state machine for project work. It determines where a task is, who can act, which actions are valid, and where accepted, rejected, failed, or escalated work goes next.

{% hint style="info" %}
**Use this area when:** you are designing production operations, adding review, introducing a model, or changing how work is assigned and completed.
{% endhint %}

### How this area fits into production

```mermaid
flowchart LR
  A["Project"]
  B["Annotate"]
  C["Review"]
  D["Rework"]
  E["Complete"]
  F["Model or specialist"]
  A --> B
  B --> C
  C -->|accept| E
  C -->|reject| D
  D --> C
  B --> F
  F --> C
```

![Unitlab workflow canvas](https://292810646-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FGjVLUz4wthGkGlRKM6rM%2Fuploads%2FAjCMPQRpjcxTkfYgo8FQ%2Fworkflow-canvas.png?alt=media\&token=941ab2b3-7827-408e-978c-b7cf80252715)

*The canvas makes stage ownership and routing visible; a production workflow should expose normal, rejected, failed, invalid, and escalated paths clearly.*

### What this area controls

### Workflow canvas

A new project receives the default workflow:

```
Project → Annotate → Review → Complete
```

The six stage types currently released in the editor are:

* **Project** — the single entry point;
* **Annotate** — human labeling;
* **Review** — human quality review with approve and reject routes;
* **Model** — automated inference on entry;
* **Archive** — terminal set-aside state;
* **Complete** — terminal successful state and release-readiness destination.

The released stage catalog contains Project, Annotate, Review, Model, Archive, and Complete. A team that needs specialist or expert review adds and names another Review stage, then configures its eligible reviewers and routing rules.

The canvas supports:

* adding stages;
* drawing connections;
* naming the workflow;
* binding the reusable workflow to a project;
* configuring eligible annotators or reviewers per human stage;
* allowing or preventing self-assignment;
* allowing manager override;
* hiding unassigned work where required;
* configuring whether the stage can be skipped;
* selecting a model, thresholds, generic type, queue scope, and class mappings for Model stages;
* accepted and rejected review branches;
* Save and Apply with impact validation;
* zoom, reset, and canvas navigation.

The workspace Workflows page displays reusable workflow cards and a Create Workflow action. Opening a project’s Workflows tab goes directly to the editor for that project’s active workflow.

In the full-page editor, users drag released stages from **Add Stages** onto the canvas, connect or remove edges, select a node to edit its configuration, and use one explicit **Save & Apply** action. The Project entry node embeds project progress. Stage names are editable except Project; duplicate display names are numbered consistently in both the canvas and Task Queue.

Replacing an active project workflow while items are in flight prompts with the number of items that would reset to Project. An unsaved-changes guard protects navigation away from the editor. Workflows can also be duplicated, archived, and restored.

### Start with the right page

| Decision               | Production guidance                                              |
| ---------------------- | ---------------------------------------------------------------- |
| Build a graph          | Configure stages and routes.                                     |
| Define human action    | Set assignment and stage actions.                                |
| Add quality control    | Configure review, rework, and escalation.                        |
| Introduce automation   | Use a Model stage with explicit failure and human-review routes. |
| Change live operations | Run a workflow impact review first.                              |

### Operating boundary

* Rejection is a route back to corrective work, not an unexplained terminal state.
* Invalid annotation state is different from workflow rejection or processing failure.
* Queue visibility and actions are consequences of stage, role, assignment, and task state.

### A production-ready handoff

Every state and transition has a name, owner, valid action, success condition, exception route, and observable queue representation.