As a person whose live workflow was broken by a bad go-live or promote, I want to restore an earlier version, so that production returns to a known-good state without a destructive overwrite.
Part of #4852 (Sandbox DevX epic). Builds on version recording (#4866).
Why this is phase 1
Everything else in this epic gives people new ways to change production. This is the only way back. Shipping go live and promote without it means a bad publish leaves someone rebuilding a workflow by hand.
How to build it
Restore is a publish, not an edit.
Promote already proves you can write new content into a live workflow without taking it out of production first. Its tests say so directly: a merge must never draft or disable the workflow it promotes into. Restore reuses that half of promote, and only that half.
So: one transaction that takes the chosen version's snapshot, writes its content in as the workflow's new content, leaves the workflow live, and records the result as the next version, labelled as restored from the version it came from. The trail reads forward, and the bad version stays in the history rather than being erased.
The content comes from the snapshot and is written exactly. It does not pass through the sandbox merge. That merge matches jobs by adjacency and body, and triggers by type, so an old state run through it comes out approximately right rather than right, which defeats the purpose of a rollback.
Reuse the existing reconciler so anyone with the editor open sees the change without reloading.
What this replaces
The earlier plan had two routes: switch to draft, load the old content, go live; or seed a sandbox from the old version and promote it. Neither is right.
Drafting first takes production offline in the middle of a rollback, which is the worst possible moment for a gap in processing.
Seeding a sandbox and promoting runs the restore through the same fuzzy merge this issue already says to avoid.
Things to say out loud in the UI
A trigger added after the version being restored disappears, and the URL built from it stops working. That is correct behaviour for a revert, but nobody should discover it afterwards.
A workflow that has moved on since that version will lose the newer work. Again correct, and again worth confirming before it happens rather than warning about it as though it were a mistake.
Acceptance criteria
Not in scope
Restoring into a sandbox rather than into the live workflow. If someone wants to inspect an old version before publishing it, that is edit in sandbox plus the version view, which they already have.
As a person whose live workflow was broken by a bad go-live or promote, I want to restore an earlier version, so that production returns to a known-good state without a destructive overwrite.
Part of #4852 (Sandbox DevX epic). Builds on version recording (#4866).
Why this is phase 1
Everything else in this epic gives people new ways to change production. This is the only way back. Shipping go live and promote without it means a bad publish leaves someone rebuilding a workflow by hand.
How to build it
Restore is a publish, not an edit.
Promote already proves you can write new content into a live workflow without taking it out of production first. Its tests say so directly: a merge must never draft or disable the workflow it promotes into. Restore reuses that half of promote, and only that half.
So: one transaction that takes the chosen version's snapshot, writes its content in as the workflow's new content, leaves the workflow live, and records the result as the next version, labelled as restored from the version it came from. The trail reads forward, and the bad version stays in the history rather than being erased.
The content comes from the snapshot and is written exactly. It does not pass through the sandbox merge. That merge matches jobs by adjacency and body, and triggers by type, so an old state run through it comes out approximately right rather than right, which defeats the purpose of a rollback.
Reuse the existing reconciler so anyone with the editor open sees the change without reloading.
What this replaces
The earlier plan had two routes: switch to draft, load the old content, go live; or seed a sandbox from the old version and promote it. Neither is right.
Drafting first takes production offline in the middle of a rollback, which is the worst possible moment for a gap in processing.
Seeding a sandbox and promoting runs the restore through the same fuzzy merge this issue already says to avoid.
Things to say out loud in the UI
A trigger added after the version being restored disappears, and the URL built from it stops working. That is correct behaviour for a revert, but nobody should discover it afterwards.
A workflow that has moved on since that version will lose the newer work. Again correct, and again worth confirming before it happens rather than warning about it as though it were a mistake.
Acceptance criteria
Not in scope
Restoring into a sandbox rather than into the live workflow. If someone wants to inspect an old version before publishing it, that is edit in sandbox plus the version view, which they already have.