Going back

Every build is kept, so going back is always possible.

Find the version#

The Versions tab lists them newest first, each named after what was asked for. If you named one yourself, it stands out from the automatic entries.

Look for the name of the change you want to undo, and take the version before it.

Two different kinds of going back#

Something is wrong on live or test. Deploy the earlier version into that environment. Press Put live or Send to test on it. In a minute or two the environment is serving the old version again, with its data intact.

This is the fast fix, and it is the one to reach for when customers are affected. It does not touch the preview or the conversation.

The working copy has gone wrong. You want the preview itself back to an earlier point, so that the next build starts from there. Ask for it:

Go back to the version before the export screen was added.

Asking instead#

Often simpler than finding a version, especially for a recent change:

Undo the last change.

Put the proposals list back the way it was this morning.

The whole conversation is still in context, so this morning is something it can resolve.

The data does not go back#

Restoring a version restores the code. It does not restore the database.

If the earlier version expects fields that a later one removed, or the other way round, say so:

Go back to the version before the merge, and keep the notes people have added since.

Nothing is deleted by going back#

Deploying an old version does not remove the newer ones. They are all still there, and you can go forward again just as easily.