Every edit is a version; rollback is one operation

The scariest sentence in automation is "someone edited the live workflow". When the process that moves money or data can be changed silently, every incident review starts with archaeology. FluidGrids treats workflows as production software: immutable versions, deliberate releases, instant rollback.

Every save mints a new version under the workflow's stable key — version 4 never overwrites version 3. Status walks an explicit lifecycle: DRAFT while you iterate, ACTIVE when deliberately released, ARCHIVED when retired. Editing an active workflow creates a draft alongside it; the active version keeps serving triggers, untouched, until you choose otherwise.

Activation is the release act, and it carries real semantics: activating a version arms its scheduled triggers, deactivating disables them atomically. The 06:00 cron is running version 3 right up until the moment you activate version 4 — there is no window where "which version is live?" has a fuzzy answer.

When version 4 misbehaves in production, run history makes the case — every run records the exact workflow key and version it executed, so failures attribute to v4 specifically, not to the workflow in general. Rollback is one operation: restore re-mints the previous version's content as the newest version, and the schedule is back on known-good behavior in seconds.

For compliance-minded teams this is the difference between asserting and proving: the full version trail per key, the run-to-version pinning, and lifecycle mutations each guarded by their own permission — so the person who can edit a draft is not automatically the person who can activate it. The version auditors see is provably the version that ran.