Skip to content
Villelab LXDGet a quote

SCORM vs. xAPI for onboarding: what actually matters for small L&D teams

SCORM 1.2, SCORM 2004, xAPI and cmi5 explained in plain terms, with a simple way to decide which one your onboarding modules need based on your LMS and what you want to measure.

By Álvaro Villena · · 5 min read

If you've asked a vendor for an onboarding module, you've probably been asked "SCORM or xAPI?" and felt you were supposed to have an opinion. For most small L&D teams the honest answer is: it depends on two things, your LMS and what you want to measure, and it's usually a quicker decision than the acronyms suggest.

Here is the plain-language version, followed by how I'd decide for an onboarding program.

What these standards actually do

An e-learning standard is an agreement between a course and a learning platform about two things: how the course is packaged and launched, and what the course reports back. Without one, every course would need custom integration work for every LMS.

SCORM 1.2

SCORM (Sharable Content Object Reference Model) is maintained by the U.S. Department of Defense's Advanced Distributed Learning (ADL) Initiative (opens in a new tab). Version 1.2 dates from 2001 and is still the most widely supported option. A SCORM 1.2 package is a ZIP file with a manifest. The LMS launches it in a browser window and the course reports a small, fixed set of data: status (such as completed, passed or failed), a score, time spent and a bookmark so learners can resume.

Its limits are real but rarely matter for onboarding. The data it reports is basic, it only works while the learner is inside the LMS, and the space a course has to save its progress is small (4,096 characters in the 1.2 data model). That's enough for a module of an hour or so with a few decision points, but tight for a long course with a lot of saved state.

SCORM 2004

SCORM 2004 is the later edition of the same standard. It adds a larger progress-storage limit, separate "completion" and "success" statuses, and sequencing rules that let a package control the order of its parts. Those sequencing rules are powerful, but LMS support for them varies, and they add testing work. Unless you need the LMS to enforce a strict path through several lessons inside one package, they are rarely worth it for onboarding.

xAPI

xAPI (Experience API, sometimes called Tin Can) is also stewarded by ADL, and its specification is public on GitHub (opens in a new tab). Instead of a fixed set of fields, a course sends statements in the form "actor, verb, object", such as "Sam answered question 3 with option B", to a Learning Record Store (LRS). It can track activity outside an LMS (in an app, a simulation or a job aid) and record much more detail than SCORM.

The catch: you need an LRS, and someone has to decide which statements matter and build reports on them. Many LMSs now include one, but the reporting is often thin, and raw xAPI data is not useful until somebody turns it into a question you care about.

cmi5

cmi5 (opens in a new tab) is a set of rules on top of xAPI that defines how an LMS launches a course and what it reports, so xAPI courses behave more like SCORM ones in an LMS. If your LMS supports cmi5 and you want xAPI-level detail with predictable LMS behavior, it's worth asking about. Support is growing but less universal than SCORM.

A comparison you can take to your LMS admin

SCORM 1.2 SCORM 2004 xAPI cmi5
What it reports Status, score, time, bookmark Same, plus separate completion and success Any activity you define xAPI statements with defined launch rules
Where it works Inside the LMS Inside the LMS Anywhere that can send data to an LRS Launched from the LMS
What you need An LMS (almost any) An LMS that supports 2004 An LRS and reporting An LMS with cmi5 support
Effort to test Low Medium Medium to high Medium

What matters for an onboarding module

Compatibility beats capability

The best standard is the one your LMS runs reliably. A beautifully instrumented xAPI module is worth nothing if your LMS imports it but your managers can't see completions in their usual report. Before picking, ask your LMS admin three questions:

  1. Which standards does our LMS accept, and which do we already use for other courses?
  2. Where do completions and scores show up, and who looks at them?
  3. Can the vendor get a sandbox account to test the package before launch?

The third question matters most. Testing in your own LMS, not only in a generic test runtime, catches the problems that waste a launch week: a module that doesn't resume, a score that doesn't record, a completion that never fires.

Decide what you need to know

For most onboarding programs the questions are simple: did the new hire finish, did they pass, and when? SCORM 1.2 answers all three. If you also want to know which choice people made in a scenario (for example, how many new hires accepted a teammate's shortcut before learning why they shouldn't), that's where xAPI earns its keep, as long as someone will actually read that data.

A useful test: if you can't name the report you'd build from the extra data and who would read it every month, you don't need the extra data yet.

Keep it simple when one module is several pieces

Onboarding modules often combine a video, a guide and a scenario. Packaging each piece as its own SCORM package lets you assign them separately, track each one, and swap one out later without rebuilding the rest. Packaging everything as one multi-part SCORM 2004 course with sequencing is possible, but it's more to test and more to break.

My rule of thumb

  • Start with SCORM 1.2 if your LMS supports it and you care about completion, score and time. That covers most onboarding programs, and it's the format that moves between LMSs most easily if you change platforms later.
  • Use SCORM 2004 if your LMS standard is 2004, or you need separate completion and pass/fail results.
  • Consider xAPI or cmi5 when you have a specific question that only detailed activity data can answer, an LRS that someone looks at, and an LMS that handles it well.

Whichever you pick, make the vendor show you the package running in your LMS before you sign off. The standard on the quote matters less than the module working in front of your learners.


The sample module on our home page ships as three SCORM 1.2 packages (video, guide and scenario) that you can download and upload to your own LMS sandbox to see how they report. If you're deciding on a format for your onboarding program, book a 30-minute call and bring your LMS admin's answers.

Planning an onboarding module?

Book a 30-minute call with Álvaro Villena. Bring your source material and your questions; you’ll leave with a scope you can take to your stakeholders, whether or not you work with the studio.