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.

​
Call compiling

Before a script version can take a call, it has to compile. Compiling can take anywhere from under 30 seconds for a simple script to more than 5 minutes for a complex one (lots of flows, tools, or knowledge base content) — and it behaves differently in each environment.

​
Test

A draft compiles every time you save it. Opening Test Call right after a save means Voxworks may still be compiling that draft — for simple scripts this is barely noticeable, but on a complex script it can delay the call actually connecting while you wait for compiling to finish.

​
Live

Clicking Publish doesn’t switch the Live version over instantly — the newly published version has to compile first. Live calls are never blocked or dropped while this happens:
  • During compiling, Live calls keep using the highest previously-published version that compiled successfully — the version you’re replacing, not the one you just published.
  • Once compiling finishes, new Live calls pick up the newly published version automatically. Calls already in progress are unaffected either way.
If a publish fails to compile, the previous successfully-compiled Live version simply keeps answering calls — nothing goes down while you fix the error and republish.

​
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.