Review and publish

When you save a Runbook, the platform builds a fresh draft of the workflow. Review and publish is where you compare the draft to what is currently live, see what changes for in-flight work, and ship.

Audience: builders

Open the Review and Publish tab

Inside the Runbook tab, switch to Review & Publish. The hero shows the build status (Ready to publish, Building, Queued, Build failed) and an audience toggle that picks the lens you want.

Pick the right lens

The audience toggle drives what you see below the hero.

Plain language (default). A change banner with counts, a numbered overview of what the workflow does, and one card per changed step. Designed for the outcome owner who needs to know what shifts, not which JSON keys moved.
Workflow detail. Two side-by-side panels: the currently published workflow on one side, the draft on the other. Each step renders as a prompt diff with token-level adds and removes, plus the workflow spec compared field by field. Designed for the builder validating the compiler's work.

Both views run off the same compare model. Switching between them never changes the underlying decision; it changes the surface you read it from.

Read the impact summary

Click Publish draft. The confirm dialog reads the App's live state and renders three impact rows.

Enabled triggers. How many triggers will switch to the new version on publish, with the first few trigger titles listed.
Queued and running work items. What happens to work already in flight. Running work items finish on the current version; queued work items start on the new version when they run.
Trigger inputs changed. Only shown when the input contract changed. Triggers that don't supply the new fields will fail until the upstream callers are updated.

If the input contract changed, fix the upstream triggers (webhook payload shapes, scheduled inputs, API ingest callers) before you publish. The impact row tells you the change is coming; it does not block the publish.

The confirm dialog also reads the version label. When there is a current live version, the header says "Publish a new version of this workflow?" and the description names the version about to be replaced. The first publish reads as "Publish this workflow?" without a version label.

When publish is disabled

The Publish draft button stays disabled until the build is Ready to publish.

Build status must be ready

If the latest save is still Queued or Building, wait for the build to finish (the panel refreshes on its own). If it shows Build failed, open the Edit tab, fix what the error message points to, and save again. See Author the Runbook for the save loop.

A draft must exist

The very first publish of an App only enables once there is a draft workflow to publish. Save the Runbook once to queue the first build.

No competing remote changes

If someone else saved the Runbook while you were editing, the Edit tab shows a banner with "Load latest saved copy". Reconcile first, save, then publish.

What happens at publish time

Publish swaps the App's current managed 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.

The earlier-tab behavior is the bridge that keeps history readable through a contract change. See Inputs, outputs, and work item contracts for the orphan-output pattern in detail.

There are open platform tasks here. The compiler is moving toward keeping slot keys stable across compiles so backward-compatible Runbook edits stop renaming output keys, and toward pinning each work item's output contract to the version it ran against. Until those land, treat slot renames as breaking changes even when the rename is cosmetic.

Discarding a draft

The Edit tab has a Discard edits button when there are unsaved changes. It reverts the editor to the last saved Runbook. The server-side compiled draft stays as it was.

Discarding an already-compiled draft from the server is a platform follow-up. Today the way to abandon a compiled draft is to edit the Runbook back to the previous shape and save, or to publish through it.

Versions and rollback

Every publish creates a new version. The currently published version shows as a label like v3 in the Review and Publish hero, and the publish confirm dialog names which version you are replacing.

See Versions and rollback for the version timeline, promoting an earlier version back to live, and the audit trail of publish actions.