Skip to main content

Publishing a journey cannot be undone

Audience: whoever configures care pathways in a live deployment.

The workflow engine's own page explains how versions work. This page is about the consequence an operator has to plan around, because it cannot be reversed after the fact.

The rule​

A published workflow version is immutable. Structure is editable only while a version is a draft. Publishing snapshots it and bumps the version number, and from that moment the version cannot be edited, withdrawn or deleted.

To change a journey you create a new draft version, edit that, and publish it in turn.

Why it works that way​

Running instances refer to the version they started under.

If a published version could be edited, editing it would change the pathway of visits already in progress — retrospectively altering what the record says happened during care that had already been given. A patient's record would then describe a journey nobody actually followed.

Versioning instead means every in-flight instance stays on the definition it began with, and the new version applies from the next instance onward. That is what makes the record answerable later.

What this means before go-live​

  • Publish deliberately. There is no "unpublish". A mistake is corrected by publishing a further version, not by removing the bad one — and the bad one remains in the history.
  • Expect version sprawl, and name versions accordingly. A journey that changes monthly will have twelve versions a year. That is the system working; plan for the list being long.
  • Changing a journey does not migrate visits already running. If a change must apply to in-flight visits, that is an operational exercise — the engine will not do it for you, deliberately.
  • Only published definitions can be mapped to a visit type. A journey built but never published is invisible to check-in, which is one of the commonest "check-in does nothing" causes.

⚠ The related failure: a visit type with no journey​

A visit type mapped to no journey still opens the visit and still issues its token. It simply starts no pathway.

That state used to be completely silent — the visit opened, the token printed, and the pathway did not run, so a misconfigured visit type looked exactly like a working one. The configuration health panel now reports it. Check it before go-live rather than after the first clinic.

See also​

  • Workflow engine internals → engines/workflow.md
  • The user-facing walkthrough → the patient journey in the User documentation