> 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/change-a-live-workflow.md).

# Change a live workflow

A live workflow change can alter assignment, permissions, queue visibility, review paths, automation, and release timing. Treat it as an operational migration.

Workflows are reusable workspace definitions that can be bound to multiple projects. Saving an active graph is therefore not a cosmetic edit. Before applying a change, Unitlab validates reachability, required edges, terminal stages, and the effect on in-flight items.

Important UX rules:

* exactly one Project and one Complete stage;
* Project has no incoming edge and must lead to an entry stage;
* Review has one Approve and one Reject route;
* terminal stages have no outgoing routes;
* every stage is reachable from Project;
* duplicate outgoing action names are rejected;
* a stage holding active items cannot be silently deleted;
* sensitive automated-stage configuration cannot change while occupied without resolving the impact.

When an active workflow change would strand work, Unitlab returns an apply-impact conflict instead of silently moving or losing items.

### Use this in production

* Capture the current graph, stage IDs, task counts, assignees, priorities, open Issues, and automation dependencies.
* Define how every in-flight stage maps to the new graph.
* Test each role and route in a controlled cohort before applying the change.
* Monitor queues, failed work, unassigned tasks, reviewer availability, and release timing after rollout.
* Record owner, reason, affected population, migration result, and rollback decision.

{% hint style="warning" %}
Do not edit a live graph only to improve its appearance. Every stage and edge can be an operational dependency.
{% endhint %}