Ship a version, not an accidental edit.

Edit a draft while the published workflow remains the active reference for new conversations. The distinction lets a team prepare a change without silently modifying a live journey.

Review the draft as a planned version before deciding it is ready to publish.

Validation identifies incomplete connections, invalid configuration, and other issues before publication. Errors stop a publish until they are resolved, while warnings call attention to a decision that deserves review.

Treat the validation result as a release checklist for nodes, branches, variables, and configured business actions.

Publishing creates an immutable workflow snapshot. That snapshot provides a stable explanation of what the runtime was instructed to do at a specific release.

A later draft does not rewrite the contents of an already published version.

An ongoing conversation stays pinned to the workflow version that started it. The customer does not switch into a different branch structure halfway through a journey because a newer version was published.

Version pinning gives support and operations a precise version to inspect when a conversation needs review.

Version history gives the team a sequence of published workflow snapshots to inspect. Use it to compare the release context around a customer outcome or a change in workflow behavior.

History is a record of versions, not a substitute for validating the next draft.

Rollback is currently a support-assisted process; contact support when a published workflow needs to be restored. Self-service rollback is planned and is not presented as an available one-click operation.

Until self-service rollback is implemented, validate the draft and its error paths before publishing a new version.