Restore an earlier configuration snapshot
An activation that turns out to be wrong in operation has to be quick to undo. Restore makes the state that was active last the active one again — a way back by exactly one step, not into the history.
The running example is the active Version 3, activated on 12 July 2026: since its activation the item export to the web shop has been failing. The cause has not been found yet, but the export is meant to run again today — so back to Version 2.
What you need
- At least one archived configuration snapshot. A snapshot moves into the archive as soon as a draft is activated over it.
- The Configuration — Activation permission at the Full level.
Restoring resets the configuration — it does not undo what the old configuration has already caused in the target system. So check beforehand what the activation actually changed: clicking the archive row opens the comparison of that version against its predecessor. Sometimes what sits there is a single wrong line that can be corrected in the draft in five minutes — then that is the better way.
Restore
- Open the Configuration Versions page and go to the Archived Configurations section. The states are listed in descending order, with version, activation time, and the user who activated them.
- Find the row of the direct predecessor of the active configuration — Version 2 in the example. Restore is offered there and nowhere else; on every older row the action is absent.
- Click Restore and read the confirmation dialog. It names the target version and states that the state active until now is archived in turn.
- Confirm with Restore. The focus starts on Cancel — the confirmation is meant to be clicked deliberately.
What happens
| The restored state | becomes the active configuration snapshot again and applies to new runs from now on. |
| The state active until now | moves into the archive — it is not lost, it moves down one row. |
| An existing draft | is preserved and can still be activated separately. The dialog says so explicitly when a draft exists. |
| A validation result obtained earlier | no longer applies, because it was obtained against a different active state. |
The last point is the one people miss: after restoring, a new validation is required before the next activation, even if the draft has not changed. Yesterday's green tick applies to a configuration that no longer exists in that form.
Further back than one step
You can repeat the procedure. After restoring, the next-older archived state is the new direct predecessor, and Restore moves down one row in the archive. Going from Version 5 to Version 2 is therefore three passes, one after another.
Two things are worth bearing in mind. Every intermediate state is briefly the active one — a run starting at that moment works with it. So switch off the automation of the routes concerned before you go back several steps in a row. And the further back you go, the less the archive row tells you about what that state actually holds: clicking the row shows only the difference to its predecessor, not to today's state. So put it up against the active configuration directly, through the selector in the comparison, before you take the first step.