Workflow versioning

How versions are created

Every time you save a workflow, that save becomes a new version. There is no separate "publish" step and no version numbering you control.

Autosave is off by default in the workflow editor. Nothing is versioned until you press Save (⌘/Ctrl + S, or the Save button top-right). This is deliberate: an autosaving editor would commit half-finished edits over a known-good state. The cost is that closing the tab mid-edit loses the edit entirely.

Which version a call actually runs

The current version is what new deployments use. Active deployments keep running against whatever version they launched with.

This is the part that catches people out. If you have a campaign running and you fix a broken Ask node, the running campaign does not pick up the fix. It finishes on the old version. You need to stop and relaunch the deployment for the change to reach live calls. Check outbound-campaigns and api-deployments for how deployments are started and stopped.

The upside is that a bad save cannot break calls already in flight. The downside is that "I fixed it and it's still wrong" is almost always a deployment still pinned to the old version, not a failed save.

Rolling back

Rollback is a dashboard operation. There is no API endpoint for listing or restoring workflow versions.

1. Open the Finn: View All Finn → your Finn → Edit Workflow.
2. Open History in the editor.
3. Pick a version.
4. Click Restore.

Restoring does not delete anything. The restored state is written forward as a new current version, so your history stays linear and you can roll forward again to the version you just backed away from.

If a workflow that used to work has stopped working, check history before rebuilding it. A restore takes seconds and tells you immediately whether the regression came from a workflow edit or from something outside the workflow (a changed prompt, a changed knowledge base, a broken integration). Agent-level configuration versions separately, see agents-versioning.

Export and import

Workflows export to JSON from the editor's ⋯ menu.

• Export as JSON downloads the current canvas state.
• Import from JSON replaces the canvas with the contents of the file.

Import overwrites the canvas. It does not merge. If you import into a Finn that already has a workflow, everything on the canvas is replaced, and that replacement only becomes a version once you save. If you imported by mistake, close the editor without saving and nothing is lost.

Three things this is useful for:

Copying a workflow between Finns. Export from one, import into another. Useful when you have a working intake flow and want a second Finn with the same structure but a different identity and voice.

Copying between accounts. Export from a development workspace, import into production. The workflow structure travels. What does not travel is anything the workflow points at by ID or by connection: calendar connections, CRM field mappings, webhook URLs, transfer destinations. See integrations and tools-transfer. After an import across accounts, open every Action node and reconnect it. An Action node pointing at a calendar that does not exist in the target account will fail at call time, not at import time, so you will find out on a real call unless you test first.

Version control outside the platform. Commit the exported JSON to git. This gives you diffs, blame, and branches that the in-editor history does not. It is a one-way mirror though. Committing a JSON file does not change the workflow. You have to import it back and save.

What versioning does not cover

Restoring an old workflow version therefore does not restore the agent it ran inside. If you changed the prompt and the workflow on the same day and the calls got worse, rolling back the workflow alone may not recover the old behaviour.

After any restore or import, test before you deploy. Use Test on Chat to walk the branches and Test on Call for the end-to-end path. Details in workflow-testing.