Skip to content
EdgeKit

Undo a change

There is no rollback, no restore of an earlier version and no per-record revert. To undo a change you make the draft say what it said before, then stage and deploy it. The undo is a new version at the end of the log, and every earlier version stays in the log as it was.

1. Find the version that made the change

Section titled “1. Find the version that made the change”

Open Delivery › Deployments › Versions. To narrow the log:

  • type a version number, the name of who deployed it, or part of a changed record’s identifier as the log shows it, in the search box;
  • filter by Changed (the kind of record), Impact (behavioural or presentational only), Moved or Deployed by;
  • open an edition from Edition: Behavioural lists versions with at least one behavioural change (every EdgeKit release counts as one), Catalog lists versions that changed products, offers or capabilities.

Filters inside one facet are combined with OR, and filters across facets with AND. Open a row to see every record it changed.

The log identifies each changed record and what happened to it. It does not show the values a record had before, so you re-enter those yourself.

2. Edit the draft back

Section titled “2. Edit the draft back”

On each record’s own screen, change it back and save. A record that was deleted is created again; it starts again at version 1, not at its old number.

3. Stage and check the preview

Section titled “3. Stage and check the preview”

Stage the draft (see Stage and deploy a change) and read the preview. It holds your undo and every other change pending in the draft. If one of those is not ready to ship, change it back in the draft too, or leave it out of the next deploy where its screen offers that.

4. Deploy

Section titled “4. Deploy”

Deploy the preview. Your sites start answering from the new version shortly after.

A record you changed back gets a new version number. If the bad change moved it from v3 to v4, the undo moves it to v5, not back to v3.

Recovering from an urgent mistake

Section titled “Recovering from an urgent mistake”

The steps are the same when a change is denying access to users who should have it. Time to recover is the time it takes to make the edit, stage and deploy. Disabling the record is also a draft edit: it takes effect at the next deploy, not before.