Skip to main content
Use Branches to keep work isolated, test it safely, and publish onto Live without disturbing anyone else. This page covers the everyday workflows. For how the model fits together, see Deployments.

​
Quick reference

​
Publishing

Publishing merges your Branch onto Live and creates a new version in Live’s history.
1

Test your Branch

Run simulation tests, or talk to the agent over an in-app call or chat. Move it to Staging first if you want to test on a real channel, such as a phone number.
2

Sync if you are out of sync

If Live has moved on, sync and resolve any conflicts before you publish.
3

Publish, and add a description

Say what changed and note anything a future collaborator should know.
A published version includes FAQs, Sources configs, functions, agent settings, response controls, routing rules, API integrations, and test sets. Everything else a Branch can do sits in its actions menu on the Deployments page: rename it, view its history, compare it with Live, move it to Staging, publish, or archive it.
Use descriptive version descriptions. For example: “Added Spanish language support with new voice”, “Fixed booking function timeout”, “Updated holiday hours”.
Sources content is synced separately. Sync sources before publishing so the latest content is available.

​
Rolling back

Roll back when a new version has critical bugs, performance degrades, or customer complaints spike.
1

Open Live's version history

Every publish is a version there.
2

Select the last known good version and roll back

Live returns to that version in one step.
Afterwards, investigate the issue, fix it in a Branch, and publish when ready. Because publishing merges rather than replaces, nobody else’s publish can silently undo your rollback.

​
Comparing Branches

1

Open the Publish menu and choose Compare changes

You can compare your Branch with Live, any two Branches (including a Sub-branch with its parent), or two versions in Live’s history.
2

Review the diff

Green for additions, red for deletions, blue for edits.
You can compare knowledge, functions, flows, variants, and settings.

​
Deployment workflows

​
Everyday change

  1. Create a Branch from Live.
  2. Make the change and test it.
  3. Publish, with a descriptive note.

​
Hotfix

  1. Create a Branch from Live, so you start from exactly what is running.
  2. Reproduce the issue, fix it, and test.
  3. Publish and monitor closely.
Because the Branch branches off Live and merges straight back, no in-progress work rides along with the fix.

​
Feature built by several people

  1. Create one shared Branch for the piece of work.
  2. Each person creates a Sub-branch from it and tests their own changes.
  3. Merge each Sub-branch back into the Branch as it is finished.
  4. Test the Branch as a whole, then publish.

​
Seasonal updates

  1. Apply the seasonal changes in a Branch, such as hours and policies.
  2. Test, then publish for the right date.
  3. Revert with a new Branch, or roll back, once the season ends.

​
Best practices

  • Publish regularly. Do not accumulate too many changes in one Branch.
  • Run tests before publishing. Tests run on any Branch or Sub-branch, so you catch regressions before anything merges.
  • Sync early. If your Branch is marked out of sync, pull the changes in rather than leaving conflicts to pile up.
  • Monitor after publishing. Watch the first 30 minutes closely and check metrics for 24 hours.
  • Know your rollback target. Identify the last good version before you publish.
  • Use consistent descriptions. Tags such as [HOTFIX], [FEATURE] and [SEASONAL] make history easy to scan.
Last modified on September 15, 2026