Skip to content

Versions and Publishing

Versions let you edit workflows safely as drafts, then publish locked snapshots that entry points can route live traffic to.

Workflow versions separate editing from production routing. The workflow record stays stable as the container, while each version represents a specific snapshot of the graph, configuration, prompts, tools, variables, and phone behavior at a point in time.

There are two operating states that matter most:

  • A draft is editable and safe for ongoing changes.
  • A published version is locked and ready for production routing.

The usual lifecycle looks like this:

  1. Create or open a draft.
  2. Change Builder or Configuration as needed.
  3. Save the draft while you iterate.
  4. Test the draft.
  5. Publish it when it is ready.
  6. Route entry points to that published version when production traffic should use it.

This model keeps live traffic stable while you continue improving the next draft.

  • Draft Editable in Builder and Configuration, but not available for production entry-point routing.
  • Published Locked for stability and available for live routing from Entry Points.

If you need to change a published workflow, create a new draft from it instead of editing the live version directly.

  1. Open a workflow draft.
  2. Build the graph and update configuration.
  3. Click Save Draft to preserve edits.
  4. Test the draft with representative messages.
  5. Click Publish Draft.
  6. Enter a useful version description.
  7. Confirm publish.
  8. Update entry points if they should route to the new version.

Treat the publish description as an operational note, not filler text. It should explain what changed and why someone might choose this version later.

Create a new draft from a published version

Section titled “Create a new draft from a published version”
  1. Open the published workflow version.
  2. Click Edit.
  3. Octo creates a new draft based on the published version.
  4. Make changes in the draft.
  5. Save, test, and publish when ready.

This is the normal way to improve production workflows safely. A published version stays stable, and the new draft becomes the next candidate for release.

Use the versions drawer when you need to understand how a workflow changed over time.

  • Review which versions are draft or published.
  • Check publish dates and descriptions.
  • Confirm the source version when a draft was created from an earlier published snapshot.
  • Open the exact version that handled a real interaction before making fixes.

Publishing a new version affects new traffic after routing changes. In-progress conversations continue on the workflow version they started with, which keeps execution stable while you iterate.

That means a version rollout is forward-looking: new interactions can move to the new version, while active ones finish on the version they already started with.

  • Save the latest draft changes.
  • Test the happy path and at least one failure or fallback path.
  • Confirm tool calls, transfer paths, and branch conditions still work.
  • Write a version description that explains the release clearly.
  • Update entry-point routing only when the published version is ready for production traffic.

Can I revert to an older version? Open the older version, create a new draft from it when available, test it, and publish it as the current version.

Why can entry points only use published versions? Published versions are locked snapshots. This prevents unsaved builder edits from changing production channel behavior unexpectedly.