unit U1 — 1 of 5

Versions & publishing

draft vs published, in-flight runs, rollback

A flow that is running is a flow you cannot freely edit. The engine keeps a published version serving live traffic and a draft you work in, and the two are deliberately separate: your half-finished mapping does not touch production until you publish it. The moment a client depends on an automation, "just tweaking it" stops being a private act — it is a release, and it needs the same care as any other deploy.

Publishing swaps the version that new runs use. It does not reach into runs already in flight: those finish on the version they started with, which is what you want — a run halfway through a three-step CRM write should not suddenly find itself executing a different step three. That also means a bad publish does not corrupt in-flight work, but it does affect everything that starts one second later, so the blast radius is "every trigger from now on."

Where it breaks: editing the published version directly because the change "is only one field." A renamed key in a mapping is exactly the kind of one-field change that silently writes empty values downstream, and without a previous version to compare against you cannot tell what changed or roll it back. Work in the draft, publish deliberately, and keep the version history — it is the only diff you have.

worked example

The version lifecycle for a client flow, and what each transition does to traffic already moving through it.

v3  PUBLISHED   <- every new trigger runs this
v4  DRAFT       <- your edits live here; no traffic

  publish v4
     |
     v
v3  ARCHIVED    <- runs that STARTED on v3 finish on v3
v4  PUBLISHED   <- every trigger from this moment runs v4

  a bad v4?
     |
     v
  re-publish v3   (the version history IS the rollback)

field checklist

Make every change in the draft, never the published version.
Treat publishing as a release with a blast radius, not a save.
Expect in-flight runs to finish on the version they started.
Keep version history so you have a diff and a rollback.
Note what changed and why before you publish it.

common failure — A one-field edit with no way back

An agency renamed a mapped key directly on the published version to match a client’s new CRM field. The old name was still referenced two steps later, so every run after the edit wrote blank values, and with no prior version to compare against nobody could say what had changed. Work in the draft, publish as a deliberate act, and keep the previous version available so a rollback is one click rather than an archaeology exercise.

check your understanding

You publish v4 of a flow at 14:00. A run that triggered at 13:59 is still executing its third step. Which version does that run finish on?

next unit opens once this is passed

sandbox validation

The check above confirms you followed the unit. Marking the module COMPLETED takes more: build the automation in your own engine and submit the exported flow and its run evidence, signed, to your unique validation URL. See the module page for that spec.