Publishing

TL;DR:

• Changes in the Scenario Editor are local until you click Save.
• Saving updates the Draft version in the database.
• Publishing makes the saved draft live for your Telegram users.
• The Publish button is enabled only when the saved draft differs from the published version.
• If you have unsaved changes, the system will save them before publishing.

Who this is for

• Bot Builders preparing their automation for production.
• Support Managers updating live bot flows.
• QA Teams validating changes before release.

What you will learn

• The difference between Local Changes, Draft, and Published versions.
• What exactly happens when you click Save.
• What exactly happens when you click Publish.
• Why the Publish button may be disabled.
• How to safely move changes from editor to production.

Overview

Scenario editing follows a clear lifecycle:

1. Local Editing
2. Saved Draft
3. Published Version

When you work inside the Scenario Editor, changes are applied locally first.
They are not stored in the database until you click Save.

Publishing is a separate step that promotes the saved draft to production.

Key concepts

• Local Changes --- Edits made in the editor that are not yet saved.
• Draft Version --- The latest saved version in the database.
• Published Version --- The version currently used by the live Telegram bot.
• Unpublished Changes --- A difference between the saved draft and the published version.
• Active Payload --- The cleaned and normalized scenario configuration used by the runtime engine.

Scenario Lifecycle Diagram

The following diagram explains how a scenario moves from editing to production:

WARNING

Local changes alone do not enable publishing. Only a saved draft difference enables the Publish button. Publishing always runs validation before deployment.

How it works

1. Editing

When you modify the scenario (move nodes, edit text, change logic), the editor shows a save status:

• Unsaved changes
• Saving...
• Saved
• Save failed

Moving a node (changing its position) is considered a change and must be saved.

2. Saving your Changes

When you click Save (or use Cmd/Ctrl + S):

• The scenario draft is updated in the database.
• The system compares the saved draft with the currently published version.
• If they differ, the scenario now has Unpublished Changes.

Saving does not affect production.

3. The Publish Action

When you click Publish, the system:

1. Validates the scenario.
2. Saves unsaved changes if needed.
3. Promotes the saved draft to the Published Version.
4. The runtime switches to the updated payload.

In the UI

Publishing controls are located in the top toolbar of the Scenario Editor.

• Save Button
• Save Status Indicator
• Publish Button

Testing changes safely

TIP

To quickly trial a single node without publishing, use Test Without Publishing — it gives you a private link that starts the bot from any node on your current draft. The workflow below is for running a full parallel copy of a scenario.

If you need to make changes to a live scenario but don't want users to see them while you test, use this workflow:

1. Duplicate the scenario — Open the scenario menu (three dots) and click Duplicate. This creates an exact copy.

2. Use a test command — In the duplicate's settings, set a test command like /start_v2 or /payment_beta. This way it won't conflict with the live version.

3. Hide from menu — Disable Show in menu in the scenario settings so the test command doesn't appear in Telegram's bot menu.

4. Publish and test — Publish the duplicate and test it directly in Telegram.

5. Swap when ready — When satisfied:

   • Unpublish the old scenario (/start).
   • Rename the duplicate's command from /start_v2 to /start.
   • Publish the new scenario.
   • Re-enable Show in menu if needed.

This approach lets you maintain multiple versions and switch between them without any downtime for users.

FAQ

• Q: Does publishing disconnect active users?
  A: No. Users continue seamlessly. Their next interaction uses the newly published version.