Does SCORM use an LRS?
No. SCORM does not use an LRS. A SCORM course sends its data to the LMS through the SCORM JavaScript API, and the LMS stores it. An LRS receives xAPI statements instead. SCORM data reaches an LRS only when something translates it into xAPI, the course sends xAPI alongside its SCORM calls, or the course moves to cmi5.
The confusion is understandable. Both are about tracking learning, many platforms sell an LMS with an LRS built in, and "SCORM LRS" turns up in product pages as if the two were one feature. They come from two different specifications. SCORM defines a package and a browser-side API. The learning record store is defined by xAPI and is a web service. Nothing in SCORM mentions it, and a SCORM package contains nothing that knows an LRS exists. The wider split between the two systems is covered in LMS vs LRS.
Where SCORM data actually goes
When a SCORM course launches, the LMS places an API object in the browser window. The course finds it and calls it. Every value the course reports is a named element in the SCORM data model, passed as a string:
Initialize("")
SetValue("cmi.score.scaled", "0.84")
SetValue("cmi.success_status", "passed")
SetValue("cmi.completion_status", "completed")
SetValue("cmi.session_time", "PT12M30S")
Commit("")
Terminate("")
What happens after Commit is the LMS's own business. It sends the values to its server in whatever format it likes and saves them in its own database. The specification stops at the API: it does not define a way for another system to read those values back out. So the record of a SCORM attempt lives in one LMS, in that LMS's shape.
An LRS works the other way round. It is a server with a REST interface defined by xAPI. Anything that has the address and credentials can post a statement to it, and anything with permission can query statements back. What it stores and how it is queried is set out in what is a learning record store.
So the two do not meet by default. Getting SCORM data into an LRS always takes something extra, and there are three routes.
| Route | Who sends the statements | Change to the course | Main limit |
|---|---|---|---|
| Translate SCORM into xAPI | The LMS or player | None | Only as detailed as the SCORM data; support varies by product |
| Send xAPI alongside SCORM | The course | Extra code and LRS configuration | Two records that can disagree; credentials to manage |
| Move to cmi5 | The course, using details the LMS supplies at launch | Republish as a cmi5 package | The LMS must support cmi5 |
Translating SCORM data into xAPI
In the first route the course does not change. The LMS, or the player that runs the course, watches the SCORM calls and writes xAPI statements from them. The course above might produce this:
{
"actor": {
"account": { "homePage": "https://lms.example.com", "name": "u-10482" }
},
"verb": { "id": "http://adlnet.gov/expapi/verbs/completed" },
"object": { "id": "https://lms.example.com/courses/fire-safety" },
"result": {
"completion": true,
"success": true,
"score": { "scaled": 0.84 },
"duration": "PT12M30S"
}
}
The mapping is fairly natural. Completion and success status become verbs or result fields, the scaled score becomes result.score.scaled, session time becomes a duration, and each recorded interaction can become an "answered" statement.
The trade-offs:
- It is the least work. Existing SCORM packages stay exactly as they are.
- The detail is capped by SCORM. A translator can only describe what the course reported through the API. If the course sends a status and a score, the LRS gets a status and a score, written as statements. It does not gain detail the course never sent.
- The mapping belongs to the product. SCORM does not define it. ADL has published a SCORM profile for xAPI that describes one way to do it, but a product is free to choose its own verbs, its own activity IDs and its own timing, such as one statement per commit or one summary at the end of the attempt.
- Support varies. Some platforms do this, some do it only for their built-in LRS, and some do not do it at all. Ask what statements are produced and where they can be sent before you plan around it.
Sending xAPI alongside SCORM
In the second route the course does both jobs. It keeps making its SCORM calls so the LMS records completion and score as usual, and it also posts xAPI statements straight to an LRS over HTTP. This is how a SCORM course can report things SCORM has no element for, such as which video chapter was replayed or which branch of a scenario was taken.
The course needs three things SCORM does not give it:
- The LRS address and credentials. SCORM has no mechanism for handing these to content, so they must be configured in the course or fetched from somewhere when it starts.
- An actor. The course can read
cmi.learner_idandcmi.learner_name(cmi.core.student_idandcmi.core.student_namein SCORM 1.2) and build an xAPI actor from them. Those identifiers are whatever the LMS uses internally, so the same person launched from two LMSs may appear as two actors. - A network path. The learner's browser must be able to reach the LRS, which is usually on a different domain from the LMS, and the LRS must accept requests from the page the course runs in.
The other cost is that there are now two records. The LMS holds the SCORM result and the LRS holds the statements, and they are sent separately. If the statement request fails on a poor connection while the SCORM commit succeeds, the two disagree. Decide in advance which one is the record of completion. For most organisations that is the LMS, with the LRS used for the extra detail.
When cmi5 is the cleaner answer
cmi5 exists to remove the improvising in the second route. A cmi5 course is still a package the LMS imports and launches, but it reports xAPI statements to an LRS by design. At launch the LMS passes the course what it needs on the launch URL: the LRS endpoint, the actor, a registration, an activity ID, and a fetch URL where the course collects its authorisation token. Nothing has to be written into the package.
cmi5 also fixes the vocabulary. It defines the statements that mark a session and its outcome, including initialized, completed, passed, failed and terminated, and it says which side sends each one. A completion therefore means the same thing whichever tool built the course. There is one record, in the LRS, and the LMS works from those same statements.
The limits are practical. The LMS must support cmi5, and fewer do than support SCORM. An existing SCORM zip does not become cmi5 by renaming it: the course has to be published again as a cmi5 package. If your LMS does not import cmi5, the first two routes are what you have.
A short way to choose:
- You want existing SCORM results visible in an LRS and nothing more: ask whether your LMS translates them.
- You need detail SCORM cannot hold and the LMS only takes SCORM: send xAPI alongside, and treat the credentials with care.
- You are building new content and the LMS supports cmi5: use cmi5.
How the three standards compare beyond the LRS question is in SCORM vs cmi5 vs xAPI.
Where SCORM Central fits
SCORM Central turns PowerPoint, PDF, and video files into SCORM 1.2 or SCORM 2004 4th Edition packages you can edit in its course builder, and its free tester shows the manifest checks and every runtime call a package makes before an LMS sees it. See how it works, or test a package free.