Somebody rewrote your returns article, and the new version is worse. Maybe it dropped the one paragraph everybody actually needed, or it went out half-finished, or the change was correct in October and wrong in November. Whatever happened, you want the old wording back and you would rather not reconstruct it from memory.
Your knowledge base keeps a version history for exactly this. It is quietly automatic, it works differently from the way most people assume, and one of its properties is genuinely reassuring once you know about it: the rollback itself is reversible.
Where the history lives
Open any article in the editor and look at the side panel. Under the heading Version history you will see one row per stored version, newest first, each with a version number, the article status at that point, a timestamp, and a Restore button. If nothing has been captured yet, the panel says so plainly: no prior versions yet, saves will be snapshotted here.
There is no switch to turn this on. Every save you make in the article editor snapshots the previous state first, whether the edit was a full rewrite or a corrected typo.
A version is the state before an edit, not after it
This is the part that surprises people, and getting it backwards will make the list look off by one.
When you save an article, the system snapshots the article as it was a moment ago and then applies your change. So the row at the top of the history is not what you just wrote — what you just wrote is the live article. The top row is the version your save replaced.
Read the list that way and it makes sense: each row is a restore point, an answer to the question what did this article look like before that edit. To undo the change you just made, you restore the newest row in the list, not the second one.
The first restore point is not the original
Version numbering starts at one, and version one is the first snapshot ever taken for that article — which is to say, the state it was in immediately before its first edit after version history existed.
The consequence matters if your help center predates the feature. An article written two years ago and never touched since has no history at all, and the first time you edit it you create version one, which captures the article as it was just before that edit. That is a perfectly good restore point. What does not exist is a version zero, an original as first authored. For older articles the history begins the day you next touch them, not the day they were written.
If you are about to make a risky change to a long-untouched article, the practical move is to save it once without changing anything meaningful. That creates the restore point before you start.
What a snapshot actually contains
A version stores the fields that make the article what it is: the title, the slug, the category, the body, the excerpt, the publication status, the sort order, and the flag that controls whether the article is available to your AI assistant.
Two things follow from that list. First, a restore is not only a content restore — it puts the status and the AI flag back too. Rolling back an article that was a draft at the time will return it to draft, which is usually what you want and occasionally a surprise if you had published it since. Second, anything that is not on that list is not versioned. View counts, votes and other accumulated signals belong to the article, not to a snapshot of it, and they carry on across a restore rather than being rewound.
The rollback is itself reversible
Press Restore and you are asked to confirm, with a note that current edits will be snapshotted before the restore so you can roll back. That is exactly what happens, and it is worth understanding because it removes most of the risk from using this feature at all.
Restoring runs in three steps: it reads the version you picked, it takes a fresh snapshot of the article as it stands right now, and then it writes the old version back over the live article. Because of that middle step, the state you just replaced is now itself a numbered version in the list. If you restore the wrong one, you restore your way back out of it.
Those pre-rollback snapshots are the only rows that arrive with an explanatory note attached, recording which version was being restored at the time. Ordinary saves store no note, so a row with a note is a reliable sign that somebody performed a rollback at that moment rather than a normal edit.
Why the history can have gaps, and why that is deliberate
Snapshotting is best effort. If taking the snapshot fails, the save still goes through.
There is a second and more predictable gap: version history is written by the article editor. An article changed another way — through the API, or by a bulk process rather than a person opening the page — is updated without a version being recorded. If you maintain help content programmatically, keep your own record of what changed, because the panel will not show it.
That is a deliberate trade and the right one: an editor who has just written four paragraphs should not lose them because a history table was briefly unavailable. But it does mean the history is a strong record rather than a guaranteed complete one, and a missing version does not announce itself. Treat the panel as a safety net that is almost always there, not as a compliance-grade audit trail. If you need a guaranteed record of who changed what and when, the place to build it is your own process — a change note in your team channel, or a review step before publication.
A routine that keeps this useful
Save deliberately rather than continuously. Every save is a restore point, so an editor who saves forty times while drafting produces forty rows and buries the one that matters. Draft in longer stretches and save at meaningful moments.
Before a big rewrite, take the free restore point described above. Before you restore, read the version you are about to bring back — the row shows the status and the timestamp, and an old version that was accurate in March may name a price or a policy you have since changed. Restoring is fast, so the temptation is to do it first and read afterwards, which is how a stale promise gets republished to your customers.
And when an article keeps getting rolled back, treat that as the signal it is. A page that two people keep rewriting in opposite directions is not a versioning problem; it is an unresolved disagreement about what the answer should be, and the history panel is only recording the argument.