Skip to main content

​
What are environments?

Every call in Voxworks runs in one of two environments:
  • Live — real calls with real callers, running the published version of your script. This is the default: inbound calls, outbound calls from New Call, scheduled calls, batches, and automations all run Live.
  • Test — calls you place while building and refining, running a draft version of your script. Test calls ring your own phone or your browser, never a customer. A real caller can also reach you through the Test environment — any call placed on a number set to Test is classified Test even though a genuine customer is on the line — but unlike Live, it doesn’t run a published, version-controlled script: it always answers with the newest saved draft, revisions and all.
The environment is decided per call, and it follows your script’s version history: published whole-number versions (v1.0, v2.0) are Live, while every other saved version is a draft that only test calls can run. Both inbound and outbound calls can run in the Test environment: an inbound call is Test when it arrives on a number set to Test, and an outbound call is Test when it dials out from a number set to Test — set the number to Live and calls in that direction run Live instead. Because the split happens at the call level, your test activity sits alongside production activity in the same account — same scripts, same contacts, same Call Log — but each call is clearly badged Test or Live, so you can always tell them apart and filter one out. Three things in Voxworks carry an environment: Scripts themselves don’t have an environment — they have versions. A script’s published version answers Live calls and its drafts answer test calls, which is what links the two systems together. See Script Versions & Publishing for the full version model.

​
How a call gets its environment

You never set a call’s environment directly — Voxworks derives it from which script version the call runs: Two consequences of this model are worth knowing early:
  • A script must be published at least once before it can take real calls. Until its first publish there is no Live version to run — only test calls work, and 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.
  • Drafts never leak into production. Editing and saving a script changes only its draft versions; the Live version keeps answering calls until you deliberately click Publish.

​
When a change takes effect

A saved change is usable on the very next call — there is no separate preparation step to wait for. Voxworks prepares the script when the call starts, in both environments:
  • Test — a test call always runs the newest saved draft. Save, then call: what you hear is what’s on screen.
  • Live — clicking Publish promotes your working copy to the new Live version, and new Live calls pick it up straight away. Calls already in progress finish on the version they started with.

​
Test Calls

The most common way activity lands in the Test environment is the Test Call button — in the script editor header, as the Test Call row action on the Scripts page, and inside the New Call modal. A test call:
  • Runs the exact version you have open — unsaved edits are silently saved as a new draft first, so what you hear is what’s on screen.
  • Offers two modes: In Browser (a call directly in your browser tab) and My Phone (Voxworks rings the phone number saved against your user profile).
  • Is recorded in the Call Log with a Test badge, exactly like any other call — transcript, summary, and Post-Call Analysis included.
  • Skips Do Not Call Register screening. DNCR washing protects the public from unsolicited calls; a test call only ever rings your own phone or browser, so the check does not apply.
  • Still consumes call minutes from your wallet — you’ll see an “Insufficient wallet balance” message if your balance is too low to place one.
The builder-side loop — save, prepare, call, refine — is covered on Testing Your Script; the operational detail of both call modes lives on Test Calls.

​
Test numbers

Each phone number on the Numbers tab under Numbers & Routing carries its own Test or Live label. Click the label to switch it — a small menu offers Live and Test.
  • A Live number (the default) answers with the assigned script’s published version. This is what every production number should be set to.
  • A Test number answers with the assigned script’s newest saved version — drafts included — and every call on it is classified Test.
A Test number is the best way to rehearse the full inbound experience: dial it from any phone and you’re talking to your latest draft over a real phone call, complete with routing, transfers, and tools, without touching the version your customers hear. The same applies in the other direction — outbound calls that dial through a Test number run as Test calls too. Switch the number back to Live when you’re done. A production number left on Test answers with your newest draft, not your published version.

​
Test integration connections

Some integrations can hold two connections at once — one per environment. In Integrations, open an integration’s settings and look at Connection Details: integrations that support this show an API Key row with a Live badge and a second API Key row with a Test badge, where you can add or remove a test key. On a call, the connection is chosen by the call’s environment:
  • A Test call uses the Test connection when one exists, and falls back to the Live connection when it doesn’t — so test calls keep working even before you add a test key.
  • A Live call only ever uses the Live connection. It never falls back to a test key.
This lets you point test calls at a sandbox account — test bookings land in a sandbox calendar, test records in a sandbox CRM — while production calls keep writing to the real one. Whether an integration offers a Test connection is configured per integration in the Voxworks catalogue and there is no screen to enable it yourself. If you need a test connection for an integration that doesn’t currently show one, speak to the Voxworks team for further custom configuration. See Integrations Overview for connection statuses and the settings modal in full.

​
Reacting to the environment in your script

Your script can tell which environment it’s running in through two system variables, set at the start of every call: Insert them in any supported field by typing /. They’re the right guard for side effects that must not fire during testing — for example, a condition on a flow branch that sends a real SMS or books a real appointment only when {{call.is_prod}} is true.

​
Keeping test data out of your reporting

Test calls appear in the Call Log alongside real ones — deliberately, so you can review their transcripts and Post-Call Analysis the same way. When you want production-only numbers:
  • Filter the Call Log. Add a filter on the Environment column — it offers Live and Test with is / is not operators. Environment is not Test gives you a production-only view.
  • Save it as a view. Click Save View to keep the filtered table as a tab next to All, so your production view is one click away every time you open the Call Log.
  • Check the badge before you trust a row. Every call shows its environment in the table, and a call’s details show a Test badge next to the script name — a quick sanity check when a result looks odd.
The environment model is built around one loop:
  1. Build your script in the editor. Saves create drafts; nothing you do here affects callers.
  2. Test with Test Call — In Browser for quick iterations, My Phone to hear it over a real line, or dial a number set to Test for the full inbound experience. Every one of these calls is badged Test.
  3. Publish when a test call sounds right. The Publish to production dialog promotes your working copy to the new Live version — see Script Versions & Publishing.
  4. Go live. Live numbers, outbound calls, and batches pick up the new Live version automatically. Keep production numbers on Live, and keep an Environment is not Test saved view for reporting.
Repeat the loop for every change: because drafts only run as test calls, you can refine a script in production hours without a caller ever hearing work in progress.

​
Next Steps

  • Test Calls — In Browser vs My Phone, the DNCR exemption, and how test calls appear in the Call Log.
  • Script Versions & Publishing — how drafts and Live versions work and what publishing does.
  • Testing Your Script — the editor’s Test Call loop, from silent draft save to connected call.
  • Call History — the Call Log’s Environment column, filters, and saved views.