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

# Environments: Test vs Live

> Every call in Voxworks runs in one of two environments — Test or Live. Learn how calls, phone numbers, and integration connections carry an environment, how activity ends up in Test, and how to keep test data out of your production reporting.

## 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](/calls/history) — 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:

| What                    | Where you see it                                                                                                               | Values                                 |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------- |
| Calls                   | The **Environment** column in the [Call Log](/calls/history), and a **Test** badge next to the script name in the call details | **Test** or **Live**                   |
| Phone numbers           | The **Numbers** tab under **Numbers & Routing** — each number shows a **Test** or **Live** label you can change                | **Test** or **Live**, default **Live** |
| Integration connections | **Integration Settings → Connection Details** — integrations that support it show separate **Live** and **Test** API keys      | One connection per 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](/scripts/versions-and-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:

| Call                                                                  | Phone Number Setting                              | Version it runs                                           | Environment |
| --------------------------------------------------------------------- | ------------------------------------------------- | --------------------------------------------------------- | ----------- |
| Inbound call                                                          | Number set to **Live**                            | The published (Live) version                              | **Live**    |
| Inbound call                                                          | Number set to **Test**                            | The newest saved version, drafts included                 | **Test**    |
| Outbound call — **New Call**, scheduled, batch, automation            | Number set to **Live**                            | The published (Live) version at the moment the call dials | **Live**    |
| Outbound call — **New Call**, scheduled, batch, automation            | Number set to **Test**                            | The newest saved version, drafts included                 | **Test**    |
| [Test Call](/calls/test-calls) from the script editor or Scripts page | — (rings your own phone or browser, not a number) | The exact draft you had open                              | **Test**    |

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](/calls/history) 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](/scripts/testing); the operational detail of both call modes lives on [Test Calls](/calls/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](/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:

| Variable           | Type    | Example | Description                                              |
| ------------------ | ------- | ------- | -------------------------------------------------------- |
| `{{call.is_prod}}` | boolean | `true`  | `true` when the call is running in the Live environment. |
| `{{call.is_test}}` | boolean | `false` | `true` when the call is running in the Test environment. |

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](/calls/history) 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.

***

## Recommended workflow

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](/scripts/versions-and-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](/calls/test-calls) — In Browser vs My Phone, the DNCR exemption, and how test calls appear in the Call Log.
* [Script Versions & Publishing](/scripts/versions-and-publishing) — how drafts and Live versions work and what publishing does.
* [Testing Your Script](/scripts/testing) — the editor's Test Call loop, from silent draft save to connected call.
* [Call History](/calls/history) — the Call Log's Environment column, filters, and saved views.