Active workflows

What publishing does

Publishing takes the exact draft revision that a successful safe test covered and stores it as a numbered, immutable version. The version records the content and routing it was published from, the approval policy versions it binds, the safe test that qualified it, who published it, and when.

Publishing does not activate anything. A newly published version changes nothing about how documents are handled until you activate it, and activation is a separate, separately recorded step.

Why Publish stays unavailable

The Publish control is unavailable until the workflow is genuinely ready. RS1 re-checks every condition on the server when you open the panel, so the button reflects saved state rather than what is on screen. Publishing needs all of the following at once: you hold the Workflow publish permission; the draft is valid with no blockers; every approval policy it references is valid and belongs to the same organization; and the most recent safe test covered this exact draft revision and checksums with zero side effects.

If any of those is missing, the panel lists what is outstanding. Editing the draft or a referenced approval policy makes earlier test evidence outdated, so a new safe test is needed before publishing.

What an immutable version means

A published version cannot be edited or deleted, and neither can the record of any transition applied to it. There is no edit or delete control, and the database refuses the change even if one were attempted. To change behaviour you publish a new version and move the active route to it; the earlier version stays on record.

The five transitions

Each transition is recorded in an append-only history with who made it, when, and why.

• Activate — make a published version the active one for a route that has none.
• Deactivate — leave the route with no active version. Nothing is deleted.
• Reactivate — make a route active again after it was deactivated.
• Supersede — move the active route forward to a newer published version.
• Roll back — move the active route back to an earlier published version.

Why a reason is required

Deactivate, reactivate, supersede, and roll back each need a short written reason of up to 500 characters. The reason is stored with the transition and shown in history, so a later reader can see why the active version changed without reconstructing it. Activate accepts an optional reason because it is the first transition on a route.

Rolling back preserves everything

Rolling back sounds destructive and is not. It changes only which version future documents will select. Every published version, every transition, and every safe test remains exactly as it was, and you can move forward again afterwards by superseding.

How a route is chosen

An organization may have at most one active default workflow. Alongside it you can activate conditional overrides, each with its own priority, for particular document types or conditions. RS1 refuses an activation that would leave two routes competing for the same document at the same priority, and tells you which workflow it conflicts with, so a document can never have an ambiguous answer.

Comparing versions

Version detail shows a structured comparison between two versions: routing changes, steps added, removed, moved, or reconfigured, and any change to which approval policy version a step binds. The comparison is derived on the server from the stored versions, not from anything on screen.

What this does not do yet

Publishing and activation decide which version future documents will select once the workflow runtime is enabled. They do not start a workflow, move a document, create an Accounting or Operations record, send a notification, or change anything about documents already in progress. Existing Capture documents continue on the current Capture lifecycle.