Two ways of thinking that do not say the same thing
For ordinary content, the question does not arise: you fix a typo, replace an image, and everyone should see the fix as quickly as possible. Automatic updating is then a quality.
Regulatory training follows a different logic. Its version is not a production detail, it states what the company asked its employees to know at a given time. “The most recent” describes the state of a file. “In force” describes a decision: someone approved this content and chose to apply it from a certain date.
A tool that confuses the two makes that decision for you, at the moment a designer uploads a file.
Three cases where the most recent is not the right one
The version has not been approved yet
The designer has finished the new version and uploads it for compliance to review. If uploading means publishing, learners take it before it is approved. If the review calls for corrections, part of the population will have been trained on content that was never validated.
Not every entity switches on the same day
A new procedure applies at head office on the 1st of the month, and in a subsidiary the following quarter, once its tools have been adapted. During that period, both versions are legitimate, each for its own population. A tool that only knows “the latest” cannot represent that situation.
An error is found after publication
A quiz question is wrong, a threshold was copied incorrectly, a link points to the old procedure. The right reaction is to go back to the previous version immediately, then fix things without urgency. If the only possible move is to upload a new version, you end up fixing in a hurry, in front of learners.
What about learners who are part-way through?
Changing the version in force always raises the same question: what do you do with those who started the old one? Letting them finish avoids losing their progress. Making them restart guarantees they see the new content. Neither answer is universal, but it should be a choice, made knowingly, and not the default behaviour of a tool.
The questions to ask your tool
| Question | Why it matters |
|---|---|
| Who chooses the version served? | If it is the file upload, nobody decides |
| Can you prepare without publishing? | Review has to come before delivery |
| Can you go back? | It is the only quick answer to an error |
| Is the version recorded? | Without it, the proof rests on inference |
| Is the change logged? | An audit will ask who decided, and when |
These questions apply to an LMS as much as to a delivery tool. They can be checked in ten minutes on a test module, and it is better to do it before the next audit than after.
Where Sajay Dispatch fits
Sajay Dispatch was designed around this distinction. Uploading a new version changes nothing for your learners: it stays a draft until you publish it as the version in force. When you publish, you choose whether learners in progress finish on the old version or restart on the new one.
You can go back to the previous version. Every publication and every rollback is written to the administration log, with its author. And every launch records the version actually served, the learner and their result.
Your learners keep their LMS, which only receives a lightweight package imported once.