How versions keep a live workflow safe to edit

A published workflow is never a single, mutable thing you edit in place. It is a workflow that points at one numbered version, and that version is the only one receiving live events. Every time you open the editor, you are working on a version of the graph, and the rules around when a version goes live, and what happens to your edits while it is live, are what let you keep changing a busy automation without breaking the runs already moving through it.

This page explains the two lifecycles you are actually managing, why editing a live version creates a draft instead of changing what is running, and why a version swap leaves in-flight runs alone.

Two lifecycles, not one

There are two separate status systems, and conflating them is the most common source of confusion.

The workflow is the durable container. It has a name, a status, and a pointer to whichever version is currently live. Its status answers "is this automation dispatching events at all?"

The version is one editable snapshot of the graph (the trigger plus its connected nodes). Its status answers "where is this specific snapshot in its path from draft to live?" A workflow can hold many versions, each numbered (v1, v2, and so on), but only one of them is live at a time.

You change version statuses directly when you publish, activate, or deactivate. You almost never set a workflow status by hand. The workflow flips to Published automatically the moment one of its versions becomes Active, and drops back to Draft automatically when the last active version is deactivated.

Workflow statuses

Version statuses

This is the lifecycle the rest of the page is about. A version moves through these states as you build, publish, and retire it.

Why editing a live version is safe

Here is the part that surprises people: when you change the graph of an Active version, TaskJuice does not modify what is running. It forks.

The moment you make a graph change to an active version, TaskJuice creates a brand-new Draft version with the next version number, labelled Draft from v<N>, and puts your changes there. The active version is left untouched and keeps dispatching events the whole time. The editor moves you over to the new draft so you can keep working.

This means your edits are not live yet, no matter how many you make. They sit in the draft. The active version is still the one handling every incoming event. Only when you publish the draft does anything change for live traffic.

One detail worth knowing: only graph changes fork. Renaming the version label, for example, does not create a draft, because it does not change what the workflow does.

How the swap happens

Publishing a draft is what atomically swaps which version is live. The sequence is the same whether it is your first publish or your fortieth:

1. Publish the draft

   From the editor, publish the draft version. TaskJuice compiles the graph into an executable plan and runs any configured publish checks.

2. The new version becomes active

   When the checks pass, the new version transitions to Active.

3. The old version steps down

   Any other active version of the same workflow is automatically moved to Inactive in the same operation. There is never a window with two active versions, and never a window with none.

4. New events route to the new version

   From this point, incoming events are handled by the newly activated version. The workflow stays Published throughout.

You can also step a version down without replacing it. Deactivating an Active version moves it to Inactive and keeps its compiled plan, so reactivating it later is fast and skips recompilation. A version that is already Inactive can be activated directly without rebuilding it.

Why in-flight runs are not disrupted

The swap changes which version receives new events. It does nothing to runs that are already moving.

Every run is pinned to the version it started on. When a trigger fires, the run records the version it began with and follows that version's compiled plan from the first step to the last. Activating a newer version does not reach back into a run that is already underway and reroute it. The run finishes on the plan it started with.

So when you publish v3 over v2:

• Runs that started on v2 continue and complete on v2's plan, exactly as they would have.
• Every event that arrives after the swap starts a fresh run on v3.

This is what makes the swap safe for a busy workflow. You are not pausing traffic, draining a queue, or migrating live executions. The old version keeps serving the work it already accepted, and the new version takes everything that comes next. For more on what a run is and how it progresses, see the run model.

Limits and edges worth knowing

A few realities of the lifecycle that are easy to trip over:

• Deprecated is terminal. Once a version is deprecated, it cannot be brought back. Step down to Inactive instead if you might want it again.
• You cannot publish a version that is mid-publish. Trying to publish a version that is already Compiling or Evaluating returns a 409 with the message "Workflow version is currently compiling. Please wait." Wait for it to settle, then retry.
• A version that is already Active is not republished. Publishing it again simply reports that it is already published and active.
• You can only publish from certain starting points. A version is publishable from Draft, Inactive, Failed, or Eval failed. Other states are mid-transition and are not valid starting points.
• Safety pauses block publishing. While a workflow is in Paused (safety), you cannot publish, activate, or deactivate any of its versions. Resume the workflow from its page after fixing the misconfiguration, then publish as usual.

Next steps

• Publish a version walks through testing a node, clearing publish-check errors, and pushing a version live.
• What a workflow is covers the workflow-and-version model from the ground up.