Skip to main content
Lesson 5 of 6 — Learn to test and promote changes safely through Sandbox → Pre-release → Live.
Environments are how you move safely from experimentation to production. They let you test changes, review impact, and roll back mistakes without exposing real users to unfinished work. A typical deployment pipeline looks like this: Sandbox → Pre-release → Live Each environment runs a specific published version of your agent. Draft changes do nothing until they are published and promoted.

​
How environments work

Think of environments as checkpoints, not branches.

Draft

Your working state. Changes exist only for you.

Published version

A snapshot of the agent at a moment in time.

Environment

A place where a specific version is running and can receive traffic.
Multiple environments can point to the same version, but only one version per environment is active at any time.

​
The Environments page

This page shows every published version of your agent and where it is currently deployed.
  • Version name or description
  • Author and timestamp
  • Which environments it’s active in (Sandbox / Pre-release / Live)
  • An overflow menu for actions
  • Preview version – load the agent exactly as that version behaves
  • Compare versions – open a side-by-side diff
  • Rollback to this version – immediately restore a previous state

​
Environment types

Sandbox is your development and testing environment.Use Sandbox for:
  • Writing or editing KB topics
  • Adjusting rules and behaviour
  • Changing voice settings
  • Wiring or modifying actions, SMS, or handoffs
  • Confirm you are in Sandbox before editing
  • Publish frequently with short, descriptive notes
  • Test after every meaningful change
Example publish note: “Clarified late checkout KB and added SMS consent language”
  • Chat testing reflects your latest changes
  • Test calls hit Sandbox numbers, not Live numbers
  • Conversation Review shows the Sandbox environment tag

​
Publishing and promotion flow

1

Make changes

Work in Draft mode
2

Publish

Click Publish and add a clear description
3

Version appears in Sandbox

Test thoroughly in Sandbox environment
4

Promote to Pre-release

Move to staging for QA review
5

Test and review

Complete full regression testing
6

Promote to Live

Deploy to production
Nothing skips steps. If it does, something is wrong.

​
Comparing versions

The Compare versions view is your primary safety tool.

What it shows

  • Added KB topics
  • Modified content
  • Removed actions
  • Function wiring changes
  • Sample question edits

When to use it

Before every promotion to verify all changes are intentional
Example comparison insight:
  • Late checkout KB text changed
  • New SMS action added
  • No rule or voice changes
If you can’t explain every change in the diff, don’t promote.

​
Rollbacks

Rollbacks are instant and safe.
  • A KB topic misfires
  • Voice sounds wrong
  • Handoffs spike unexpectedly
  • A release introduces confusion
  1. Select a known-good version
  2. Click rollback
  3. Confirm rollback
  4. Verify with a live test call
Rollback restores behaviour immediately without deleting newer versions.

​
Phone numbers and environments

Each environment can have its own phone number.

Sandbox number

Internal testing only

Pre-release number

QA / stakeholder testing

Live number

Public traffic
This prevents accidental testing on production users.

​
Common mistakes

Avoid these pitfalls:
  • Editing while in Live without noticing
  • Forgetting to publish before testing
  • Assuming KB edits propagate automatically
  • Skipping version comparison
  • Using vague publish notes like “updates”

​
Verification checklist

You understand environments when:
  • You can say which version is live without checking
  • You know how to roll back in under a minute
  • You can explain what changed between two versions
  • You never feel tempted to “just tweak production”
If environments feel slow, that usually means they’re doing their job.