Workflows
Turn a label's candidate issues into a dependency, handoff, and acceptance graph.
A workflow takes the issues carrying a workflow-enabled label and arranges them as a node graph with explicit dependencies — which node must finish before the next can start, where work is handed from a person to an agent or back, and what "done" means for each node. It is for work whose order matters: pipelines, release trains, multi-step deliveries.
Workflows do not have a top-level navigation item. They start from the detail page of an issue label with workflows enabled.
Starting a workflow
- Enable workflows on an issue label.
- Open the label's detail page — the issues carrying that label become the candidate nodes.
- Arrange the nodes and their dependencies into a graph.
- Publish the graph.
Running a workflow
After publishing and activating, the graph drives the work:
- Readiness and blocking — a node becomes ready when its dependencies are met, and blocked when something upstream fails or stalls.
- Handoff — work moves explicitly between people and agents at the nodes where you defined it.
- Deliverable acceptance — the receiving side reviews and accepts (or rejects) what a node produced.
- Dependency-product requests — a node can request the output of another node it depends on.
- Overrides and blocker resolution — when the graph is wrong about reality, a person can force a node through or resolve the blocker directly.
- Workflow activity — every transition is recorded, so the run has a history instead of a vibe.
Actions that need a person — acceptances, dependency requests, blockers — surface in their inbox instead of relying on someone watching the graph.
Templates
A published graph can be saved as a workflow template, so the next time the same kind of work shows up you start from the known-good shape instead of re-drawing the graph.