Compare versions

​

When to use it

• Before promoting from sandbox to pre-release or live — Review all changes to confirm nothing unexpected is included.
• After a model upgrade — Verify that no unintended changes were introduced alongside the upgrade.
• When you find a draft you didn’t expect — Understand what’s in it, who made the changes, and whether to keep or discard it.
• In branching workflows — When multiple people work on the same project, use the diff to verify a teammate’s changes before merging or promoting. For example, if a customer needs a quick fix while your team is building on a separate version, compare versions to confirm the fix is isolated.

​

Key features

• Side-by-side comparison across sandbox, pre-release, and live environments
• Full platform coverage — diffs apply to knowledge base, functions, flows, variants, and settings
• Change attribution — each change shows who made it and when, which is useful for compliance, regulated industries, and multi-team projects
• Content diff for responses, sample questions, and configuration

​

How it works

1. Select versions to compare: Choose two versions of the project from the dropdown menu. You can compare across environments (for example, sandbox vs. live) or between versions within the same environment.
2. Review differences: Changes are highlighted in a structured format:
   • Additions — a new item was added.
   • Deletions — an existing item was removed.
   • Edits — an existing item was modified.
3. Check attribution: Each change is annotated with the user who made it. Use this to audit who changed what — especially useful when multiple people have access to the same project.
4. Assess impact: Use the comparison view to evaluate whether changes are ready to promote.
5. Exit comparison mode: Return to the editor or switch to another version for further review.

​

Using diffs with branching

1. A customer or teammate needs to make a quick change to the live agent.
2. They create a new version from the current live version and make the change there.
3. Before publishing, they use Compare versions to confirm only the intended change is present — nothing from an in-progress build is included.
4. They publish the isolated change to live.

​

Related pages

• Project history — View a chronological record of all project events, including published versions, draft branch merges, and deleted drafts. Use Project history to find versions to compare, audit when changes went live, and roll back if needed.
• Environments — Understand the deployment pipeline (sandbox, pre-release, live).