How a workflow is structured and goes live

A workflow in TaskJuice is two things at once, and keeping them apart explains almost everything about how your automations behave. There is the workflow itself, which is a durable container with a name and a status, and there is the version, which holds the actual graph you edit on the canvas. You design on a version. You publish a version. Live events only ever reach one version. The workflow is mostly a stable handle that points at whichever version is currently live.

This split is what lets you edit a running automation without taking it offline, and it is the source of a few behaviors that surprise people the first time they hit them. This page builds the mental model so those behaviors make sense before you meet them in the editor.

The graph: one trigger plus connected nodes

A version's graph is a set of nodes connected by edges. Every workflow has exactly one trigger, the single entry point where work begins, and a set of downstream nodes connected to it. Those downstream nodes fall into two roles: app actions (a provider operation like sending a Slack message) and system nodes (built-in steps like Branch, Loop, Transform, or an AI node).

The trigger is special because it is the only entry point. Events arrive there, and everything else runs because the trigger fired. A workflow cannot have two triggers, and a downstream node cannot become an entry point. For how the two roles differ and how one step's output feeds the next, see Triggers and actions.

The graph itself does not live on the workflow. It lives on the version. The workflow record only carries the name, the status, and a pointer to the version that is live. That separation is the whole game.

Versions: editable snapshots of the graph

A version is one numbered, editable snapshot of the graph. Versions start at 1 and increment. Each version carries its own canvas and its own lifecycle status, independent of the workflow's status.

You almost never create a version by hand. TaskJuice creates them for you as a side effect of editing and publishing. The important thing to hold onto is that a version is the unit you edit and the unit you publish. When you open the editor, you are looking at a specific version's graph.

A version moves through its own set of states as you work on it: draft while you build, a brief compiling state when you publish, then active once it is live, and inactive if you take it back offline. There are additional states for validation and failure cases. The full version lifecycle, including how a live version is swapped without disrupting runs already in progress, is covered in Versioning.

Draft versus published: which version receives live events

This is the load-bearing rule:

When you publish a version and it becomes active, four things happen automatically:

1. Retire the previously live version

   Any other active version of the same workflow is flipped to inactive. A workflow has at most one live version at a time.

2. Repoint the workflow at the new version

   The workflow's pointer to its live version updates to the version you just published.

3. Mark the workflow as published

   If the workflow was in draft, its status flips to published. This happens for you; you do not set it by hand.

4. Wire up the trigger

   The workflow's trigger subscriptions are configured and enabled so that real events start flowing to the new active version.

The reverse is just as automatic. If you take the last active version offline (back to inactive), the workflow's trigger stops receiving events and the workflow drops back to draft. Nothing arrives at a workflow with no active version.

Why the workflow status and the version status are different

It is easy to assume there is one status. There are two, and they answer different questions.

The workflow status is derived from its versions. You do not toggle a workflow to published directly. It becomes published when one of its versions becomes active, and it returns to draft when no version is active anymore. Keep this in mind when you read a status badge: a published workflow means one version is live, not that every version you have ever drafted is somehow active.

Editing a live workflow forks instead of overwriting

Here is the behavior that surprises people, and it is intentional.

When you edit the graph of an active version, TaskJuice does not modify the running version. It creates a new draft version containing your changes, labeled Draft from v<N>, and leaves the active version untouched and still running. The editor then drops you into that new draft.

So if v3 is live and you start rearranging nodes, you are now editing v4 as a draft. Live events keep flowing to v3 the entire time. Your changes do nothing to production until you publish v4. Publishing the draft is the single atomic step that swaps which version is live.

This fork-on-edit behavior is what makes the swap safe. Because the active version is never mutated in place, there is no moment where a half-edited graph is receiving events. You build the next version in full, then flip to it.

Note that only graph changes fork. Editing a version's label by itself does not create a new draft, because it does not change what the workflow does.

Runs already in progress are unaffected by a swap

When you publish a new version, you are not interrupting work that is already running. Every run is pinned to the version it started on. A run that began on v3 finishes on v3's graph even after you make v4 live. New events that arrive after the swap go to v4.

This means a publish is genuinely non-disruptive. There is no draining step you have to perform and no window where in-flight executions break. Old runs complete on their original version; new runs start on the new one. For the full lifecycle and the validation that happens between pressing publish and the version going live, see Versioning.

A worked example

Say you are running a workflow that posts new form submissions to Slack.

• The workflow is published. Version 2 is active and receiving events. Version 1 is inactive.
• A teammate reports the Slack message is missing the submitter's email. You open the editor and add a field to the message.
• The moment you change the graph, TaskJuice creates version 3 as a draft, labeled Draft from v2. You are now editing v3. Version 2 is still live and still posting to Slack.
• You test the change, then publish v3. It compiles, becomes active, and version 2 flips to inactive.
• Three form submissions were mid-flight when you published. They finish on version 2's graph. Every submission that arrives after the swap runs on version 3.

At no point did Slack stop receiving messages, and at no point did a half-finished edit reach production.

When a publish is rejected

Publishing is not a single status flip. TaskJuice checks your plan limits, compiles the graph, validates it, and only then makes the version active. Two rejections are worth knowing before you hit them.

If the graph fails to compile, the publish stops and surfaces the compilation error instead of going live. The previously active version keeps running on its old graph, so a failed publish never leaves you with nothing live. Fix the reported error in the draft and publish again.

A safety pause blocks publishing entirely. If a workflow tripped a safety check, its status is paused-safety, and publish, activate, deactivate, and replay are all rejected while it stays in that state. Editing and republishing will not clear it. The only path out is to resume from safety: fix the misconfiguration that tripped the check, then resume the workflow from its page. Once the workflow is back to a normal status, your publish goes through.

What this model does not give you

A few honest limits worth setting expectations on:

• One trigger per workflow. You cannot attach a second entry point. If you need a different trigger, that is a different workflow.
• One live version at a time. Publishing a version retires the previously active one. You cannot run two versions of the same workflow live in parallel.
• Edits are not live edits. There is no mode where canvas changes hot-patch a running version. The fork-then-publish path is the only way changes go live, by design.
• A workflow with no active version receives nothing. A draft workflow, or one whose last active version was deactivated, is not wired to its trigger. Publishing is what connects it.

Next steps

• Triggers and actions covers the two node roles and how each step's output becomes context for the next.
• The run model explains what a run is, its statuses, and how to recover one.
• Versioning goes deep on the version lifecycle and the zero-downtime swap.