Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
DictionaryBBot Version
ServiceBeginner

Bot Version

A Bot Version in Salesforce is a numbered, immutable snapshot of an Einstein Bot or Agentforce Bot's configuration: dialogs, intents, training utterances, Bot Actions, channels, and entity definitions.

§ 01

Definition

A Bot Version in Salesforce is a numbered, immutable snapshot of an Einstein Bot or Agentforce Bot's configuration: dialogs, intents, training utterances, Bot Actions, channels, and entity definitions. Each saved revision of the bot increments the version. Only one version is Active at a time; that version handles live traffic. Other versions remain available as Inactive history that admins can clone, compare, or reactivate. Bot Versions are how bot programs iterate safely: build a new version in isolation, validate it, then activate it without disrupting the in-flight conversations on the previous version.

Bot Versions matter because bot quality emerges through iteration. Intent training improves as the team learns what real customers say. Dialogs evolve as edge cases surface. New channels (Slack, WhatsApp, SMS) get added. Each change risks regression on the existing version, so most production teams build major changes as a new Bot Version, test it in a sandbox, then activate it in production during a planned window. The previous version stays available for one or two cycles in case rollback is needed. The version model is also how A/B testing of major changes works; one version handles half the traffic and another handles the other half, with performance metrics compared after a measurable window.

§ 02

How Bot Versions support iterative bot delivery

The version lifecycle

Versions move through Draft, Active, and Inactive states. Drafts are editable; Active versions handle live traffic; Inactive versions are preserved history. Activating a draft demotes the previous Active to Inactive and promotes the draft. The platform handles the transition cleanly; in-flight conversations on the old version typically finish on the old version while new sessions start on the new one.

What a version captures

A Bot Version snapshot includes every dialog, every step inside every dialog, every intent and its training utterances, every Bot Action configuration, every entity definition, every variable, and every channel binding. Almost everything is versioned together; the few exceptions (channel-level routing) are configured outside the version and survive across versions.

Cloning a version to edit

The standard pattern is Clone the current Active version, edit the clone (now a Draft), test it, then activate. Cloning preserves everything; the Draft is a starting point that diverges only when the team makes explicit changes. Most production work follows this pattern weekly or monthly.

Testing a draft before activation

Drafts can be tested through the Bot Builder Preview window with simulated user input. More thorough testing happens in a sandbox where the Draft can be activated for internal users. Production teams typically run a sandbox activation for a few days before promoting the Draft to production Active.

Rollback to an earlier version

Inactive versions remain available. Activating an older version rolls the bot back to that configuration. In-flight conversations on the rolled-back version handle themselves; new conversations get the older logic. The rollback path is what lets teams ship aggressive changes without fear; if something breaks, reversion is a click.

Version comparison and diffing

Bot Builder offers limited diff capabilities between versions. Most teams rely on the version metadata stored in source control through Salesforce DX for richer comparison. Diffing dialogs and intents between versions is how teams validate that only intended changes shipped.

A/B testing major changes

For significant redesigns, some programs run two Bot Versions in parallel against split traffic. The platform does not natively split per-session; some teams use an external router (or two bots with split channel binding) to send different cohorts to different versions. Performance metrics are then compared after a measurable window.

Common pitfalls

Three patterns recur. Editing the Active version directly (skipping the clone-edit-activate pattern) risks production disruption. Forgetting to test a Draft in a sandbox produces issues only at production scale. And keeping too many Inactive versions (dozens) makes the version list unmanageable; archive or delete after the rollback window passes.

§ 03

How to manage Bot Versions safely

Bot Version management is most useful as a disciplined rhythm: clone, edit, test, activate, monitor, retire. Skipping steps invites production issues.

  1. Clone the current Active version

    Inside Bot Builder, clone the Active version to create a new Draft. Name the clone with a meaningful suffix (V12 - intent retraining, V13 - new payment dialog).

  2. Edit the Draft in isolation

    Make changes to dialogs, intents, training, or actions. The Active version continues to serve production while the Draft evolves.

  3. Test in Bot Builder Preview and a sandbox

    Run scripted conversations through Preview. For larger changes, activate the Draft in a sandbox for internal testers before production.

  4. Activate the Draft in production

    Once tested, activate the Draft. The previous Active version demotes to Inactive. Watch Bot Performance metrics closely for the first hours.

  5. Retire old Inactive versions

    After the rollback window passes (typically two to four weeks), archive or delete obsolete Inactive versions to keep the list manageable.

Gotchas
  • Editing the Active version directly risks production disruption. Always clone-edit-activate.
  • Drafts not tested in sandbox surprise the team at production scale. Most issues only appear under real customer load.
  • Keeping dozens of Inactive versions makes the version list unmanageable. Retire after the rollback window passes.
  • Cross-version channel routing changes are not versioned. Document them separately so the rollback path stays clean.
§

Trust & references

Sources

Cross-checked against the following references.

Official documentation

Straight from the source - Salesforce's reference material on Bot Version.

Was this entry helpful?
Help us write better definitions. Quick reactions or detailed edit suggestions.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.

§

Test your knowledge

Q1. How many versions of a bot can be active at one time?

Q2. What is a key benefit of Bot Versions?

Q3. What happens to previous versions when you activate a new one?

§

Discussion

Loading…

Loading discussion…