This system map is part of the course version approval guide. It is for LMS consultants who need to tell a client, before a migration or an introduction, whether its approval history can be rebuilt or only remembered.
Four systems, one approval: where each record sits
Course approval is rarely run in one tool. The request is logged in one place, reviewed in another, published in a third and signed off wherever the approver happens to reply. The table maps the usual arrangement.
| System | Record | Linking key it carries | Owner |
|---|---|---|---|
| Ticket tracker | Curriculum change request, content error tickets | Change request ID, course code | Instructional design lead |
| Content repository | Reviewer notes, marked-up lessons, review checklist | Course code and release in folder or file names, change request ID if referenced | Subject matter review board |
| Learning platform | Published release, course log, assessment with question version settings | Course code, release in course name or notes, question version numbers, publish date and user | Learning platform administrator |
| Question bank | Question versions and their history | Question ID and version number | Assessment team |
| Mailbox | Sign-off replies, remedy decisions | Approver, date, subject line naming the course | Head of learning |
| Master course copied to sections (where used) | Sync history and per-section exceptions | Associated course ID, change ID, conflict class | Learning platform administrator |
The learning platform is usually the strongest node, because it records publish dates and users automatically. Moodle keeps question versions with a viewable history, and a quiz can be pinned to a specific version rather than "Always latest", which tells you exactly which questions a release used. The weakest nodes are the mailbox and the repository, where keys exist only if people typed them.
The keys that carry a case from system to system
| Key | Appears in | Joins | What breaks without it |
|---|---|---|---|
| Course code and release number | Repository folders, learning platform course name or release notes | Reviewer notes to the published release | Notes cannot be matched to the release they approved |
| Change request ID | Tracker, sometimes repository and learning platform change log | The reason to the review and the release | No link between why a change was made and what shipped |
| Question version numbers | Question bank, assessment settings, review checklist if assessments are included | A release to the exact questions it tested | Nobody can say which questions learners saw |
| Approver and approval date | Repository sign-off, mailbox, learning platform publish log | The decision to the publish event | Chronology fails: was it approved before it went live? |
A quick test with the client: for one past release, can the learning operations head name the change request, find the reviewer notes by course code, see the assessment's version setting and point to the sign-off? Each "yes" is a working key. Each "we would have to ask someone" is a join that a migration or a staff change can break.
One joined case, end to end (Illustrative)
A fictional 220-person compliance training company. One release of a forklift operator course, followed across four systems with the key that carries it at each hop.
| Hop | From | To | Key used | What the join proves |
|---|---|---|---|---|
| 1 | Tracker: request CR-118 to add a new load chart | Repository: folder FORK-101 release 7 | Change request ID in the review checklist | The review was for this request |
| 2 | Repository: reviewer sign-off dated June 12 | Learning platform: release 7 published June 14 | Course code and release number | Approval came before publishing |
| 3 | Learning platform: release 7 assessment | Question bank: questions at version 3 | Question version numbers | Learners were tested on the revised questions |
| 4 | Learning platform: publish by the learning platform administrator | Mailbox: head of learning's go-ahead June 13 | Approver and date | The publisher had authority |
Every hop holds, so the release can be explained without anyone's memory. Change one fact, say the assessment pinned at version 2, and hop 3 exposes an exception: the case worked step by step on the exception examples page.
Master courses copied to many sections add a second layer of joins
Companies that push one master course to many sections, for different clients or cohorts, need one more key: which sections actually received the approved change. In Canvas, the Blueprint Courses API records the sections that did not receive an update as exceptions per associated course, with conflict classes such as content, points, due dates and availability dates, and lists changes not yet synced.
That turns the map from a chain into a fan. A company that kept its sync history can show not only what was approved, but which client sections never got it, and why. Ask whether that history is part of any planned export.
Gaps no key can close
Some context sits outside every system and has to be described, not joined:
- The review checklist's scope. If assessments were never on it, that absence is itself the evidence; ask whether old checklist versions were kept.
- Remedy decisions made by phone or in a meeting, recorded nowhere or in one person's notes.
- Logs trimmed by retention settings. Administrators may have set how long logs and grade histories are kept; ask what the setting is before assuming an old release is still visible.
- Export limits. Standard course exports tend to move content, not decisions. What version history each system can produce varies by platform, version, hosting and contract; the company's administrators should confirm it before the old platform closes.
For qualification, record only metadata: which nodes exist, years per node, who owns each, and who can authorize a licensing discussion, the CEO, often with the COO or general counsel advising; for background, see board approval for a data licensing agreement and whether licensing data requires board approval. Unknown until SourceX reviews it: buyer interest, the rights result for third-party course content, de-identification and any offer. The introduced company needs 50+ full-time employees at peak (contractors excluded), documented operating history, rights to license and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. Partners sign the Channel Partner Agreement first; the first valid introduction within the 90-day window is credited when the company submits a verified application.
Version history problems look similar in other systems; compare Adaptive Planning version history export and the email archive migration guide. More sectors are on the industries hub.
Adaptive PlanningNext step
Refer a company. Earn up to $100,000. Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.
If the client's four keys mostly hold and its old learning platform has a closing date, register as a partner, check the company against who qualifies, read the program terms, and put the map's answers into the referral brief template.