> ## Documentation Index
> Fetch the complete documentation index at: https://docs.voxworks.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Script Versions & Publishing

> Every save of a script creates a numbered version. Learn how Draft and Live versions work, how to publish to production, how to browse and compare version history with an AI change summary, and which version each call actually runs.

## How script versions work

Every time you save a script, Voxworks records a complete numbered version of it — the script content, its settings, and the exact state of every flow it uses. Nothing is ever overwritten: your history is a list of versions you can reopen, compare, and copy content back from at any time.

Versions come in two states:

| State     | Pill                 | How it's created                                                                       | Who runs it                                               |
| --------- | -------------------- | -------------------------------------------------------------------------------------- | --------------------------------------------------------- |
| **Draft** | Amber **Draft** pill | The **Save** button (and the draft save a [Test Call](/scripts/testing) makes for you) | Only test calls — drafts never answer or place real calls |
| **Live**  | Green **Live** pill  | The **Publish** button                                                                 | All real calls — inbound, outbound, and batches           |

Version numbers make the two easy to tell apart. Draft saves increment the number after the dot — v0.1, v0.2, v1.1, v1.2 — while publishing rounds up to the next whole number: publishing after v1.4 creates **v2.0**. The **Live** pill always sits on your highest published version; everything else shows **Draft**.

This separation means you can edit freely. Saving a draft never changes what callers hear — the Live version keeps taking calls until you deliberately publish.

Draft and Live are the version-level half of a bigger idea: every call is also tagged **Test** or **Live** depending on which number or call type it came through, and that environment is exactly what decides whether the call runs your latest draft or your published version. See [Environments: Test vs Live](/getting-started/environments) for the full model, including how compiling delays a version before it can take calls.

***

## Saving a draft

In the script editor, the moment anything differs from the last saved version a yellow **Unsaved Changes** badge appears in the toolbar. Click **Save** to cut a new draft version — you'll see a confirmation such as *Saved v1.3*, and the new version appears at the top of the version history immediately.

A few behaviours to know:

* **Save is disabled when there is nothing to save** — no accidental empty versions.
* **Validation blocks saving** — if the flow editor reports errors, saving fails with *Please fix validation errors before saving* until they're fixed.
* **Navigating away is guarded** — leaving the editor with unsaved changes opens an **Unsaved Changes** dialog ("You have unsaved changes. Are you sure you want to leave? Your changes will be lost.") with **Stay** and **Leave** options. Closing the browser tab triggers the browser's own warning too.
* **Test Calls save for you** — starting a [Test Call](/scripts/testing) with unsaved changes silently saves a new draft first, so the call runs exactly what you see on screen and the version is in your history to return to.

***

## Publishing to production

Publishing takes your current working copy — the latest version plus any unsaved edits — and makes it the Live version.

1. Click **Publish** in the editor toolbar (or open the version menu and choose **Push to production**).
2. A confirmation dialog titled **Publish to production** explains: *"This becomes the live version. All calls will be made with this script."*
3. Click **Publish** to confirm. Your changes are saved and promoted in one step, and a confirmation such as *Published v2.0 to production* appears.

Notes on publishing:

* **Publish always publishes the current working copy.** You cannot publish an older version directly — to take earlier content live again, open the [compare view](#comparing-versions), copy the sections you want back into the current copy, then publish.
* **Push to production** in the version menu is disabled when the version you're viewing is already Live.
* **Publish is blocked by validation errors**, the same as saving, and is unavailable while you're viewing an older version — switch back to the latest version first.
* **A script must be published at least once before it can take real calls.** Until its first publish, only [Test Calls](/scripts/testing) can run — a real call attempted against a never-published script is recorded as [Failed](/calls/statuses), with a System Note asking you to test the script and promote it to production.
* After publishing, the new version has to compile before it can take calls — under 30 seconds for a simple script, upwards of 5 minutes for a complex one. If the newest Live version is still compiling — or failed to compile — Live calls automatically fall back to the most recent Live version that compiled successfully, so a bad publish never stops your calls connecting. See [Call compiling](/getting-started/environments#call-compiling) for the full behaviour, including how drafts compile on every save.

***

## Version history

The version menu sits next to the script name in the editor. Its trigger shows the version you're viewing (for example **v1.3**) with its **Live** or **Draft** pill. Open it to see the **Versions** list: each row shows the version number, its **Live** pill if it's the live one, the date it was saved, and a tick on the version you're viewing. The five most recent versions show first — choose **See more** (labelled with the number of remaining versions) / **See less** to expand or collapse the rest.

Selecting a version loads it into the editor with a *Viewing v1.2* confirmation. When it isn't the latest version:

* A **Read-only** label appears next to the script name and editing is disabled.
* **Save**, **Publish**, and **Test Call** are disabled — the Test Call button hints *Switch to the latest version to test call*, and attempting to save shows *You are viewing an older version. Switch to the latest version to make changes.*

To bring an older version's content back, use **Compare** — the compare view lets you copy any section of an old version into your current copy.

Below the version list, the menu offers two actions: **Compare** (open the version you're viewing in the compare view) and **Push to production**.

***

## Editing conflicts

Two safeguards protect you when a script changes underneath you:

* **Someone else saved first.** If a teammate (or another of your own tabs) saves the script after you opened it, your save is rejected with: *This script was changed since you opened it. Reload to get the latest version before saving.* Reload the page to pick up their version, then re-apply your edits — your history keeps every saved version, so nothing they saved is lost either.
* **A shared flow changed.** Flows can be shared between scripts. If a flow your script uses was edited from another script, opening your script automatically cuts a fresh draft that picks up the change, with a confirmation such as *A referenced flow changed — saved as v1.4*. Your version history stays an accurate record of exactly what each version ran.

***

## Comparing versions

Choose **Compare** from the version menu to open the **Compare and edit** view — a side-by-side diff of any two versions.

* **Two panes, two version selectors.** Each pane has its own version picker in the header; the swap button between them flips the sides. You cannot pick the same version on both sides — the menu marks it *Already selected on the other side*.
* **Current** appears at the top of each picker as a selectable version — your in-progress working copy (unsaved edits included), so you can diff unsaved edits against any saved version before committing them. When you open Compare with unsaved changes, the left pane starts on **Current** automatically; otherwise it starts on the Live version.
* **Colour convention:** the newer version's additions highlight green; the older version's removed content highlights red — whichever side each is on. Lines that merely changed highlight only the words that differ.
* **What's diffed:** the script name, description, Call Objectives, Guidelines, Data Collection, and every conversational flow. Setting and voice changes show as chips (for example *± Setting: max call duration*, *± Voice: Olivia*), and flow-level changes show chips for added or removed flows plus *Step order* and *Stages* changes per flow.
* **Synchronised scrolling.** Both panes scroll together by default; each pane has a lock button to hold one side still while you scroll the other.
* **Edit while you compare.** The pane showing the latest version is editable; every other version is marked **Read-only snapshot**. Hover a changed section on the editable side to reveal a copy arrow — *Copy objectives from right* — that pulls that section across from the other version. **Save current** applies your in-progress edits back to the working copy (*Current copy saved*), and **Cancel** discards them. Nothing is written to history until you save or publish from the editor.
* **Shareable link.** The page address updates with the comparison you have open, so you can share a link that lands a teammate directly in the same diff.
* **Flow history incomplete** — an amber badge shown on versions saved before flow history was fully tracked. For those, the closest available flow content is shown and the flow diff may not match that version exactly.

### AI change summary

Click **Summarise changes** in the compare header to get a plain-English summary of the differences between the two selected versions. A **What changed** panel opens, shows *Reading both versions…* while the summary is generated, then presents a short write-up of what changed and why it matters. Use **Regenerate** for a fresh take. If the two versions are effectively identical it reports *No meaningful changes detected*, and the button is disabled with *No changes to summarise* when there is no diff at all. Switching either version clears the summary so it always describes the pair on screen.

***

## Which version a call runs

Every call records the script version it ran. In the [Call Log](/calls/history), the Script column shows the version next to the script name (for example **v2.0**), and the Environment column badges each call **Live** or **Test**. This is the version-level view of the same model [Environments: Test vs Live](/getting-started/environments) covers in full — that page also has the complete breakdown by phone number setting.

| Call                                                                                    | Version it runs                                                             |
| --------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
| Inbound calls on a number set to **Live**                                               | The Live version                                                            |
| Inbound calls on a number set to **Test**                                               | The newest saved version, drafts included — badged **Test** in the Call Log |
| Outbound calls — New Call, scheduled calls, automations — from a number set to **Live** | The Live version at the moment the call dials                               |
| Outbound calls — New Call, scheduled calls, automations — from a number set to **Test** | The newest saved version, drafts included — badged **Test** in the Call Log |
| [Test Calls](/scripts/testing) from the script editor                                   | The exact version you had open — unsaved edits are saved as a draft first   |
| Batch calls                                                                             | Governed by the batch's version policy — see below                          |

Because publishing takes effect at dial time, a publish applies to your very next real call — there is nothing to restart.

You can also check which version answers a phone number at a glance: the **Numbers** tab under [Numbers & Routing](/numbers/overview) shows the Live version (for example **v2.0**) next to each number's assigned script.

Your script can also tell which environment it's running in. The system variables `{{call.is_prod}}` (boolean — `true` on real calls) and `{{call.is_test}}` (boolean — `true` on test calls) are set at call start, so you can gate copy or side effects that must not fire during testing. Insert them in any supported field by typing `/`.

### Batch version policies

Each contact queued in a [batch](/batches/overview) carries a script version policy that decides when its version is locked in. By default, the version is resolved at the moment each call launches — so if you publish mid-batch, calls that already ran keep their recorded version and every remaining call picks up the new Live version. Alternative policies, such as freezing the version when a contact first joins the queue so a long-running batch is insulated from later publishes, exist at platform level but have no in-app control. Speak to the Voxworks team for further custom configuration.

***

## Next Steps

* [Testing Your Script](/scripts/testing) — run a Test Call against your draft before publishing it.
* [Script Editor Guide](/scripts/editor-guide) — a full tour of the editor the version menu lives in.
* [Call History](/calls/history) — see the version and environment recorded on every call.
* [Batch Scheduler](/batches/overview) — how batches queue, screen, and launch outbound calls.