Skip to main content

​
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: 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 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 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, 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 can run — a real call attempted against a never-published script is recorded as Failed, 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 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, 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 covers in full — that page also has the complete breakdown by phone number setting. 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 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 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