Publishing workflows
Publish a Draft Workflow into the version that live traffic, triggers and operator-facing apps can use.
The builder edits a Draft Workflow version. Builder Runs and Workflow Tests execute that Draft. Publishing creates a version that production can use.

Publishing a version
The first publication is fixed at v1.0. After that, the current Publish menu offers:
Update — publish a patch update to the current major version;
New Version — publish the next major version.

A version comment describes what changed. The Draft becomes Published with publication metadata and appears in version history.
Production serves a Workflow version only when it is:
Published;
active;
the Workflow's default version.
The first published version is made the default automatically. The Publish action is unavailable while there are unsaved changes, when the Workflow has no configured trigger, or while another publication is already in progress.
Publishing can change live infrastructure
Publishing is not only a version label. It can deploy an integration trigger before the publication transaction and synchronise the schedule when the new version becomes the default.
If schedule synchronisation fails, publication is aborted. Treat changes to triggers and schedules as production changes.
Operator-visible Workflows
Operators see published Workflows with an APP trigger through the operator-facing app experience. Drafts remain builder work.
Live runs also use real Workflow Request Inbox handoffs rather than the inline Request UI used in builder tests.
Before publishing
Test representative cases, verify the external accounts and actions the Workflow can affect, inspect failure paths and check any human handoff with the correct production assignee.
A successful builder test is evidence about the Draft path you exercised. It is not proof that trigger delivery, production assignment or every live-data case will succeed.
Last updated
Was this helpful?