Publish and version a workflow

What this achieves

Publishing turns a draft route into the one new requests follow. Versioning is what lets you change a live route without disturbing the requests already travelling down it.

Required role: Administrator.

Steps

Go to Approvals → Workflows and open the workflow.
Open the Versions tab.
Select Create New Version. It opens as a copy of the current published version, so you are editing what is live rather than starting from nothing.
Make your changes in the designer and save.
Back on Versions, use Compare with… to check the new version against the one it replaces.
Select Publish… on the new version.
Write Change notes saying what changed and why.
Confirm with Publish.

One draft at a time

A workflow holds one draft version. Selecting Create New Version when a draft already exists opens that draft rather than making a second one.

This is worth knowing when two administrators are working on the same workflow: you are both editing the same draft, and only one of you can have it open in the designer at a time.

Publishing validates first

Publishing runs validation and refuses if there are errors, whether you publish from the designer or from the versions list. A published version becomes the current version, and the version list records who published it, when, and the change notes they wrote.

Write the change notes. Six months later they are the only account of why the route changed.

What happens to requests already in flight

A published version cannot be edited. A request that has already started stays on the version it started under, and finishes on that version, following the route as it was drawn when the request was raised.

Example: HC Corp publishes v2 of its promotion route on 12 August 2026, adding a Finance step. James Whitfield’s promotion request, raised on 10 August, finishes under v1 and is never asked for the Finance approval. A request raised on 13 August follows v2 and is.

Two consequences follow:

Publishing a fix does not fix requests already running. If a live request is on a broken route, deal with that request directly — cancel it and have it raised again, or reassign the step it is stuck on.
For a period after any publish, two shapes are running side by side. Instance history will show both, and that is correct rather than a fault.

Comparing versions

Compare with… puts two versions side by side and counts what changed: steps added, removed, moved, and modified, and what is unchanged.

Use it before publishing to confirm the change is the one you intended, and after an unexpected result to see what a previous publish actually did.

Activating the workflow itself

Publishing a version is not the same as putting the workflow into service. A workflow stays in Draft until it is activated, and it cannot be activated until a version has been published — the action is unavailable until then and says so.

The sequence is: create the workflow, design a version, publish that version, activate the workflow, then bind it to the requests it should handle.

Retiring a version or a workflow

Archive rather than delete. An archived workflow stops taking new requests and keeps the record of what it decided, which is what an audit will ask for. Deleting removes it from the list.

What happens next

New requests that match a binding on this workflow follow the version you published. Watch the first few in the instances list rather than assuming — a route that validated and simulated correctly can still meet data you did not anticipate.