Publish and roll back a workflow

Saving and activating are two separate acts, in every environment. A new workflow is created as a draft by its first save; it receives no event until it is published.

Save a draft

Save the draft stores your work without activating it: a draft never receives a routed event. Drafts are validated loosely (schema only) so you can save mid-edit, and they are simulatable like any spec.

If someone else changed the workflow since you loaded it, saving fails with a conflict: reload to get their version, then reapply your change. Last-write-wins overwrites cannot happen silently.

Publish

Publish runs the full validation (schema, typed dataflow, expressions, codes, terminology, webhook address), then freezes your draft as an immutable version vN and makes it the active version, the one that handles the next incoming event. You can attach a short note (why this change); it shows up in the history.

Other published workflows on the same event type are not a refusal: every published workflow that receives an event starts, subject to its own filter (see Choose which events start a workflow). Publishing returns non-blocking warnings instead:

• when other published workflows receive the same event type, the list of them, in full at the first publication or when another receiver has been published since your current active version: Les événements BioResultReceived démarrent aussi : « bio-result » : Ajouter la condition ; « renal-alert » (filtre). and in short otherwise: Les événements BioResultReceived démarrent aussi 2 autres workflows, sans changement depuis la version active. The filter marks are explained in What else starts on the same event.
• when the trigger's event has a default filter that the workflow's filter does not contain: Événement « CommunicationReceived » : le filtre par défaut est absent du sélecteur (event.sender != "meridian").

The editor shows them under the toolbar, in the Publication warnings (v{version}) block. Triggers with their own address get neither warning, because their events are not routed by type: webhooks (the UUID in their URL), sub-workflows (the caller's execute node), schedules (the file that owns the schedule) and EAI connections (the workflows bound to the connection).

Runs already in flight are untouched: each run executes the spec that was active when it started (journaled with the run), including the sub-workflows it calls, whose versions are pinned at the same moment. So publishing a new version of a callee cannot change a run that is already under way.

Roll back

The Version history (in the workflow view) lists every published version with its author, date, and note. Restore an earlier version to make it active again, instantly, with no redeploy. Rolling back does not delete anything: the newer version stays in the history and can be re-published later. A restore returns the same warnings as a publication, shown as Restore warnings (v{version}).

Where each run's version shows

The Executions view shows the version badge (v3) each run was started with, so "which version handled this patient?" is always one glance away.