Tutorial: Deployments

PolyAcademy Level 1 – Work in a Branch, test it safely, and publish onto Live with confidence.

Lesson 5 of 6 – Before your agent goes live, you need to understand how deployments work. This is how you test safely – so changes never reach real users until you’re ready.

Every project has a Live version, the agent actually talking to your customers. You never edit Live directly. Instead you work in a Branch, your own isolated copy branched off Live, and publish it back when it’s ready.

How it works

Live

Production. The version handling real traffic. Never edited directly.

Branch

Your isolated copy of the agent, branched off Live. Publishing merges it back.

Sub-branch

Splits a Branch further, so several people can share one piece of work.

Branches and Sub-branches live in the Sandbox environment, sharing the API and app connections set up for Sandbox. Sandbox has no channel connections, so when you need to test on a channel, move your Branch into Staging. Staging is available in Branches and Sub-branches modes, and holds one Branch at a time.

The flow

Publishing merges your Branch onto Live and creates a new version in Live’s history. It never replaces Live outright, so nobody’s work gets silently overwritten.

Check your understanding

The environments

Sandbox

Sandbox is where every Branch and Sub-branch lives while you work on it.

Use a Branch in Sandbox for:

• Writing or editing KB topics
• Adjusting rules and behavior
• Changing voice settings
• Wiring or modifying actions, SMS, or handoffs

Best practices

• Check the navigation bar so you know which Branch or Sub-branch you are in
• Test after every meaningful change – your work saves as you go
• Keep each Branch focused on one piece of work

Verification

• In-app chat and call testing reflects your latest changes
• Sandbox uses its own API connections and has no channel connections, so nothing you build there can reach a real phone number

Staging

Staging is optional. Use it when in-app testing is not enough.

Use Staging for:

• Testing on a channel, the way a customer would reach your agent
• Confirming a channel is wired up correctly
• Final voice and pacing checks over a real call

Best practices

• Move a Branch into Staging once its in-app tests pass
• Only one Branch can be in Staging at a time
• Re-run your key tests over a real call:
  • Simple FAQ (Chat and Call)
  • Voice and greeting
  • Out-of-scope refusal
  • Any topics or actions you’ve added

Verification

• The Staging number reaches your Branch, not Live
• No unexpected KB topics are triggered
• Behavior matches what you saw in Sandbox

Live

Live is production. Real users are here.

Rules for Live:

• Never edit directly – create a Branch instead
• Always know exactly what version is live
• Every publish is a version you can roll back to

Best practices

• Test a Branch before publishing it
• Confirm the publish explicitly in the dialog
• Monitor first calls after publishing

Example safe publishing habit: Publish → make one test call → open Conversation Review → confirm behavior → continue monitoring

Working with others

Two ways to work in parallel:

Ship together

Share one Branch and give each person a Sub-branch. Merge each Sub-branch back as it finishes, test the Branch as a whole, then publish. Everything lands on Live at once.

Ship independently

Each person opens their own Branch and publishes on their own schedule. Branches never merge into each other; each one publishes to Live on its own.

Nobody queues behind anyone. While one team spends weeks on a new flow in their Branch, a colleague can open a small Branch, update the knowledge base, and publish the same day.

Comparing changes

The Compare changes view, in the Publish menu, 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 publish, to verify all changes are intentional

If you can’t explain every change in the diff, don’t publish.

Rollbacks

Rollbacks are instant and safe.

When to roll back

• A KB topic misfires
• Voice sounds wrong
• Handoffs spike unexpectedly
• A publish introduces confusion

How to roll back

1. Open Live’s version history – every publish is a version there
2. Select a known-good version and click rollback
3. Confirm
4. Verify with a live test call

Rollback restores behavior immediately without deleting newer versions, and because publishing merges rather than replaces, nobody else’s publish can silently undo it.

Common mistakes

Avoid these pitfalls:

• Making a quick change without noticing which Branch you are in
• Leaving a Branch out of sync and letting conflicts pile up
• Skipping Compare changes before publishing
• Testing in Sandbox when the behavior depends on a real phone call – use Staging

Check your understanding

Verification checklist

You understand deployments 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”

Try it yourself

1. Challenge: pre-publish checklist

   You’ve made three changes in your Branch: updated the pet policy topic, added a new SMS offer for late checkout, and changed the agent voice stability from 0.6 to 0.8.

   List at least 4 specific tests you would run before publishing.

   Hint

   Think about each change you made and what could have broken. Also consider: what tests should always run, regardless of what changed?

   Example solution

   1. Test pet policy topic – ask “are dogs allowed?” in both Chat and Call; confirm the correct topic triggers.
   2. Test SMS consent flow – ask “can you text me the late checkout info?” and confirm the agent asks for consent before sending.
   3. Make a test call from Staging – listen for the voice stability change over a real call; confirm no audio artifacts were introduced.
   4. Run a regression test – test a simple FAQ, out-of-scope refusal, and a handoff to confirm nothing regressed.
   5. Compare changes – open the diff and confirm the three changes are the only ones present.

Check your understanding

Go deeper

The Deployments reference covers the model in full, along with Compare changes and everyday Branch workflows:

Deployments reference

How Live, Branches, Sub-branches and Staging fit together

Compare changes

How to compare a Branch with Live side by side before publishing

Branch management

Everyday Branch workflows: publish, roll back and compare

---

← Previous: Edit voice settings

Lesson 4 of 6

Next: Conversation reviews →

Lesson 6 – see what your agent actually did