Version History & Rollback
Editing a live approval template never mutates it. It publishes a new version, and every request already in flight finishes on the version it started on.
Illustrative UI only. Data and individuals shown are fictitious; any resemblance to real persons or data is coincidental.
Edits fork, never overwrite
Publishing a change creates a new version chained to the original. Every version that ever ran is still there to inspect, with field-level change history recorded on top.
In-flight work is pinned
A request takes a full snapshot of its template at submission and reads only that snapshot from then on. Publish version seven mid-afternoon; the open version-six requests finish exactly as version six defined.
Any version can come back
The full lineage is queryable, and re-publishing a prior version makes it current again, so a rollback is really a fast-forward to a known-good state.
Migration is a decision, not an accident
When open requests should move to the new rules, forced migration moves them explicitly, reports how many moved, and audits each one with its from-and-to versions.
Why we like this one
The quiet failure mode of workflow tools is the template edit that lands mid-flight: the request approved under rules that no longer exist, or stuck on a step that was just deleted. Snapshot pinning makes the safe behaviour the default and the disruptive one an explicit, audited choice, which is exactly the right way around.
Book a demo ➝