Course version history and restoring a version
Learnient keeps the course as it was at earlier saves, so a change you regret is recoverable and a completion can be tied to the exact content somebody was trained on.
Two different histories, and they are easy to confuse
Section titled “Two different histories, and they are easy to confuse”| Where | What it shows |
|---|---|
| The History tab on the course page | An event log — status changes and who made them, as rows of Event, Detail, Person, When |
| The Version history button in the course builder | What the course contained at each save, with the option to put one back or delete it |
The first answers “who published this?”. Only the second lets you restore anything. The rest of this article is the second.
Opening a course’s version history
Section titled “Opening a course’s version history”Open the course in the builder and choose the clock icon in the toolbar at the top, labelled Version history. It is greyed out on a course that has never been saved, because there is nothing yet to show.
Looking at an earlier version writes nothing, so you can open it at any time, including on a published course that people are part-way through.
Looking at an earlier version of a course
Section titled “Looking at an earlier version of a course”Every save is a card along the top of the screen, oldest on the left, with the current one pinned at the right-hand end. Choose one to see the course as it stood at that save. The arrow keys move along the row.
Putting one back
Section titled “Putting one back”Restoring writes that version’s content back into the course and records it as a new save. It does not rewind the course to an earlier point and it does not publish anything.
That distinction matters. After restoring you have a draft change like any other, so it reaches learners only when you publish — and where your account requires a publish check, it goes through approval first.
Deleting a save from a course’s version history
Section titled “Deleting a save from a course’s version history”Each save carries a bin in its top right-hand corner. Choose it, confirm, and that save is removed from the history for good.
Deleting a save changes nothing about the course itself. The content, the current version and anything learners can see are all untouched — you are removing a record of what the course used to say, not undoing anything.
It cannot be undone. There is no bin to recover it from afterwards, which is why there is a confirmation step.
Deleting needs the same permission as editing the course, and each deletion is recorded in Audit logs, so the fact that a save was removed survives the save itself.
Why a save’s bin is greyed out
Section titled “Why a save’s bin is greyed out”Four kinds of save cannot be deleted. Hover over the greyed-out bin and it tells you which one applies.
| The save | Why it stays |
|---|---|
| The current one | It is what the course is now, so there is nothing to remove |
| A published one | Kept as the record of what learners were shown |
| One a learner is on, or was certified against | Evidence would disappear from under somebody’s completion |
| One a publish approval comment refers to | The comment would lose the content it was about |
These are the same three protections that survive automatic pruning, described below, plus the current version. Tidying a history by hand cannot remove anything the product would have kept on its own.
What creates a version
Section titled “What creates a version”Saving does, but only when something a learner would see has changed. A save that moves nothing, or changes only the styling of individual items, creates no version.
Changing a course’s Design is the exception, and deliberately so. It restyles every module at once, so it records one version — labelled Design updated — before it runs, which is what makes Undo in version history possible. One design change leaves one save, not several.
Edits made outside the canvas count too — renaming a module, adding or removing one, or a voiceover finishing in the background — so a publish approver is never shown a comparison with those left out.
Reordering modules counts, and so does ticking or unticking Show the cover page, Show the contents screen or Show the closing page. Learners see those changes when the version is published, like any other.
Publishing approves the version it publishes, whether or not your account uses publish checks. That is what ties a learner’s completion to a specific version of the content.
How long saves are kept
Section titled “How long saves are kept”Unpublished saves are pruned on two settings, found under Admin, then Learning and Course publish: how many to keep, and how many days. The defaults are 50 saves and 30 days.
The two work together as whichever keeps more, not whichever keeps less. Fifty saves and thirty days means you keep the last fifty saves and everything from the last thirty days, so a busy fortnight does not cost you the month.
What is never removed from a course’s version history
Section titled “What is never removed from a course’s version history”Three things survive however old they are, whether pruning comes for them or somebody chooses the bin:
- Published versions, kept permanently as the record of what was live.
- Any version a learner has started or been assessed on, so evidence never disappears from under a completion.
- Any version a comment refers to, so a discussion still makes sense.
Pruning runs overnight rather than at the moment a setting changes, so lowering the numbers does not take effect instantly.
If the History tab is not there
Section titled “If the History tab is not there”Version history appears only once a course has been saved at least once. A course you are creating has nothing to show yet.