Restoring an earlier version of a procedure

Each saved version carries its own performance metrics and who published it, and restoring creates a draft rather than going live.

Every published version of a procedure is saved, and each one carries the period it was live, its own performance metrics and who published it. So the history answers more than "what did this used to say": it tells you whether the earlier version worked better. Restoring creates a draft rather than going live.

View the revisions

1. In Knowledge admin, click Manage articles and select Procedures.
2. Click the procedure's name to open it.
3. Click the revisions icon in the sidebar.
4. Select a version to see its changes and its metrics. Removed content is red, added content is green.
5. Use the Show changes toggle to hide the mark-up, and Back to return to the published version.

Restore one

1. Select the version and click Restore.
2. Confirm by clicking Restore again.
3. Click the Save drop-down arrow and click Publish.

Nothing changes for agents until that last step, which is the safety net: you can restore, read the result, and think again before publishing.

It is all or nothing

You must restore the whole version; individual revisions cannot be restored on their own. Restoring therefore undoes every change since that version, including corrections you still want.

So compare first, and where you only want one sentence back, copy that sentence into the current version instead. That is usually the right move, and it is the only way to get a partial rollback.

Let the metrics decide

Because each version shows how it performed while it was live, a decline is checkable rather than a hunch. If the previous version had a better acceptance rate over its period, that is your answer.

Why a change goes wrong quietly

Editing a procedure to handle one awkward case can change the behaviour on the common case. The awkward case is what you tested; the common case is what most tickets are. That is why the effect shows up as a general decline a week later rather than as an obvious fault.

Change one thing at a time

Three edits in one sitting means you cannot tell which caused the change in behaviour, and the metrics per version cannot separate them either. Slower, and much easier to reason about when something is off.

Test after restoring

The old version was correct against the process as it was. If the process has moved since, restoring reintroduces an inaccuracy that was fixed for a reason. The revision history names who published each version, which is who to ask.

See also

• Viewing and managing procedures
• Testing a procedure
• Writing a good procedure: where it usually goes wrong