Validation, saving and versions
The right-hand side of the editor toolbar holds three buttons: Versions, Validate and Save. Here is what each one does, and how an error differs from a warning.
Validate the graph
Validate sends the graph currently on the canvas to the server and shows the result
in a bar under the toolbar. The bar reads Graph is valid when there are no errors,
otherwise it counts errors and warnings and lists the messages below.
Customer support
Graph validation
1 error · 2 warnings
| Level | Message |
|---|---|
| Error | Node 'llm_1' has no incoming execution edge |
| Warning | Two exclusive branches converge on 'exit_1' |
| Warning | Streaming output is swallowed by the barrier |
- 1Summary: how many errors and warnings.
- 2Clicking a row moves the camera to the offending node.
- 3The cross dismisses the bar until the next validation.
A row is clickable when the issue points at a concrete top-level node; the click brings
the camera to it. Issues found inside a composite body are
not clickable — such a message arrives prefixed with the composite’s id, because node ids
are only unique within their own graph.
At the same time the node cards get a badge: red means the node has an error, amber means a warning. As soon as you edit the graph the report is cleared — it described the previous state of the canvas and would misreport the new one.
Error and warning are different things
A warning is advice. It blocks neither saving nor deploying. A typical one: two mutually exclusive branches converge on a single input, so only one of them will ever arrive.
An error means the engine will refuse the graph. You can still save a draft that has errors — saving is never gated — but you cannot deploy it.
Saving
Save is enabled only while there are unsaved edits; an “unsaved” marker sits next to the workflow name meanwhile. Saving runs validation first, so the bar and the node badges match the graph — but the validation result never blocks the save.
Every save of the graph creates a new version.
If someone else saved the workflow while you were editing — another tab, or an external agent over MCP — your save will not overwrite their work: a version-conflict error appears in the issues bar and your edits stay on the canvas.
Version history
Versions opens the Version history dialog, newest first.
Customer support
Version history
Load goes to the editor, Roll back goes to production
| Version | When and who | State |
|---|---|---|
| v12 | Aug 14, 18:20 · anna@acme.io | Current draft |
| v11 | Aug 14, 12:05 · anna@acme.io | Deployed |
| v10 | Aug 13, 19:41 · lev@acme.io | — |
Each row shows the number, the timestamp, the author’s e-mail and, where applicable, a Deployed or Current draft badge.
- Load puts that version’s graph on the canvas. It does not change what is deployed, and it marks the canvas unsaved: to make the version current you have to save it.
- Roll back points what is currently live (chat, webhook, Telegram, schedule) at the chosen version. It asks for confirmation, leaves the draft untouched, and is unavailable for a version that is already deployed.
Diff and the JSON view
Under each version there is a Diff vs version N row comparing it with the previous number. Collapsed, it shows three counters: added, removed, changed. Inside it there is a View JSON link with the exact list of added, removed and changed nodes and edges.
When there is nothing between the two versions, the panel says so.