Versions and rollback

Every publish creates a new version of your App's workflow. The version label tells you which one is live and which one a publish is about to replace.

Audience: builders

Where the version shows

The currently published version surfaces in two places:

Review and Publish hero. Once your App has shipped its first publish, the build status row carries a label like v3. That is the version the platform is currently serving for triggers and manual creates.
Publish confirm dialog. When you click Publish draft, the confirm dialog header reads "Publish a new version of this workflow?" and the description names the version you are replacing. The first publish reads as "Publish this workflow?" without a label.

The version number increments by one on every publish. Read it as a sequence, not a semver: v1, v2, v3.

What changes at publish time

Publish swaps the App's live workflow to the new draft. From that moment:

New triggers and new manual creates run against the new version.
Work items already running finish on the version they started against.
Queued work items start on the new version when they get picked up.
Older completed work items keep their outputs. When the output contract changed, those outputs surface on the work item Review surface as earlier tabs.

See Review and publish for the full impact summary and what the confirm dialog shows.

Rolling back

There is no one-click rollback today. The Review and Publish surface shows the version label, and the publish confirm dialog names which version you are replacing, but the product does not yet expose a version timeline, a "promote to live" action on a previous version, or version pinning. To revert, edit the Runbook back to the previous shape, save, let it build, and publish again. The new publish increments to the next number; the older version's contents are preserved in the audit ledger.

If a published version misbehaves and you cannot wait for an edit cycle, disable the App's enabled triggers from the Triggers tab while you fix the Runbook. New work stops arriving until you re-enable them. Work already running finishes on the version it started against.

Comparing versions

The diff you see in Review and Publish is always draft against currently published: the saved Runbook you have not shipped yet, compared to the version that is serving live work.

Comparing two earlier versions against each other is not surfaced in the UI. The Runbook and compiled spec for every published version live in the audit ledger; pull the relevant publish entries from /audit filtered by your App to read what shipped when.

See Review and publish for the plain-language and workflow-detail lenses on the live diff.

The audit trail

Every publish writes an entry to the workspace audit ledger:

The actor who published.
The Runbook markdown and the compiled workflow at the moment of publish.
The publish impact summary (enabled triggers, queued and running work counts, contract changes).
A link back to the App.

Filter /audit by the App when a controller asks for the receipts. Pair with the work item ledger entries to trace which version produced any given output.