Flow States

Every version of a conversational flow is in one of three states. The state decides what the editor lets you do with that version and whether customers are talking to it. A flow usually has several versions at once: the one that is published, the draft you are editing, and the older ones kept for reference.

DRAFT

The DRAFT state is the default for new flows and for any edit you make on top of a published version. It is the version you work on.

Characteristics

• Full editing - every modification is allowed
• Autosave - changes are saved automatically
• Not in production - no customer is talking to this version

Autosave behavior

While you edit a draft, the builder saves your work by itself:

• Trigger: 5 seconds after your last change
• What is saved: nodes, connections (edges) and variables
• Paused while a node panel is open: the save runs once you close it
• Only with editor control: without control the canvas is read-only and nothing is sent (see Collaborative Editing)

The autosave indicator in the top bar shows when a save is in progress.

Saving is not publishing

A draft saves with errors on purpose - work in progress is allowed. Missing connections, unwired handles or a half-configured node never stop a save. The version customers talk to only changes when you publish.

ACTIVE

The ACTIVE state is the published version: the one connectors route new conversations to and the one running conversations execute.

Characteristics

• Live - real customers are talking to this version
• Frozen - its nodes, connections and variables do not change; an edit produces a new draft instead
• Versioned - every publish creates a new version number and keeps the previous ones

Publishing a flow

The main button of the editor reads Publish while you are on a draft. Publishing:

1. Saves the draft first, so what is checked is what you see on the canvas.
2. Runs the publish gate. Only rules that would provably break a run block the publish: no start node, duplicate or missing node ids, a connection to a node that does not exist, an invalid variable type. Everything else is a warning.
3. Promotes the draft to ACTIVE and archives the version that was published before.

You can publish with warnings. The gate lists them so you decide, but it only refuses when there are errors; in that case it points at the nodes involved and the flow keeps its current published version.

Publishing needs a draft. When the latest version is already the published one and you have changed nothing, there is nothing to publish.

Editing a published flow

Open the published version and the main button reads Save instead of Publish. Autosave does not run on a published version: your first explicit save creates a new draft (version + 1) with your changes, and the published version keeps answering customers untouched until you publish that draft.

Changing a variable's type or name from the panel follows the same rule: on a published version it forks a new draft; on a draft it updates it in place.

ARCHIVED

An ARCHIVED version is a previously published version that a newer publish replaced. It is kept for reference and for running conversations that are still on it.

Characteristics

• Not receiving new conversations - connectors route to the current ACTIVE version
• Preserved - you can open it from the versions sheet and read it
• Read-only - the canvas and the variables panel do not accept changes while you look at it

Restoring a version

Open an archived version and the main button reads Restore. Restoring creates a new draft based on that version; you can then edit and publish it. The current published version stays active until you publish the restored draft.

State Transitions

There is no direct transition from ARCHIVED to ACTIVE: restore produces a draft, and the draft goes through the publish gate like any other.

What Happens in Production

The engine never modifies a flow while executing it. What it modifies is the conversation, and every situation below leaves a notice on the conversation - visible in the notices panel of Chat and grouped in the Flow Notices screen - so you can tell what happened without guessing.

Conversations run the published version

A conversation executes the version it started on. Saving a draft changes nothing for it, and the types declared for its variables are read from that version, not from the draft (see Variables). A Jump To with no pinned version resolves the published one; it only enters a draft if you explicitly pinned it to that version.

A conversation without an active flow

A live conversation can end up without a flow to run in two ordinary ways:

• The flow it was on was deleted or is no longer active.
• A node failed and its error handle was not connected, so the flow ended.

What happens with the customer's next message depends on the connector's default responder (see Channel Connectors):

The "no flow" notice quotes why the flow ended, so you read "terminó por: Node conversational-login failed" instead of reconstructing it.

Email is the one exception: an email conversation without a flow is the human inbox by design, so only the missing-flow case leaves a notice there.

Inactivity timeout

When the connector has a Timeout, a conversation the customer left waiting on a node expires after that many seconds of silence and the timeout message, if any, is sent. The notice says how long the customer was silent, on which node type, what was sent and where the conversation went:

• info when there is a default responder and the conversation was redirected to it.
• warning when there is none and the conversation was left without a flow.

A conversation whose last message came from a human agent does not expire.

A node interrupted by a deploy

When the platform rolls out a new version while a long node is running (an extraction on an LLM, an OCR, a synchronous workflow), the node is cancelled mid-flight. The conversation is flagged and gets a warning notice with code interrupted_by_shutdown. The node runs again on the customer's next message, or on the recovery sweep that resumes flagged conversations proactively, so the customer who was told to wait is not left waiting forever.

What is not a failure

Jump To, Human Takeover and End are how flows are meant to finish or hand over. Reaching an End node closes the flow with an info notice, "Flow terminated", whose reason is end_node_reached; a Jump To moves the conversation to the target flow and a Human Takeover hands it to an agent. None of them is an error, and a conversation that reaches them is working as designed.