If you’ve spent any time evaluating learning platforms or commissioning training content, you’ve encountered the term SCORM. It appears in platform specifications, content licences and procurement checklists with enough frequency that it’s clearly important – but explanations of what it actually is tend to be either too superficial to be useful or too technical to be actionable. This guide explains SCORM in plain terms: what it does, how the different versions differ, what its limitations are and when the newer xAPI standard is worth considering instead. For a practical example of how SCORM compliant training courses work within a modern platform environment, the Staff Skills academy+ SCORM offering provides a useful reference point.
What SCORM actually is
SCORM stands for Sharable Content Object Reference Model. The name is not particularly illuminating, so here’s a more useful description: SCORM is a set of technical standards that defines how online training content and learning management systems communicate with each other.
Before SCORM existed, online training content and the platforms that delivered it were essentially incompatible unless they were built by the same vendor. A course created in one authoring tool would work in the platform it was designed for and nowhere else. This created significant problems for organisations that wanted to purchase content from multiple sources or switch platforms without losing their existing content library.
SCORM solved this by establishing a common language. A course built to SCORM standards will work in any LMS that also supports SCORM – regardless of who built the course or who built the platform. This interoperability is the core value of the standard and it’s why SCORM adoption became effectively universal across the e-learning industry through the 2000s and 2010s.
In practical terms, a SCORM package is a zip file containing the course content – HTML, JavaScript, images, audio, video – along with a manifest file that tells the LMS what’s inside the package and how to launch it. When a learner opens the course, the content communicates with the LMS through a defined JavaScript API, passing data back and forth according to the SCORM specification.
SCORM training courses: the difference between SCORM 1.2 and SCORM 2004
Two versions of SCORM are in active use and understanding the difference matters when evaluating content and platforms.
SCORM 1.2 was released in 2001 and remains the most widely supported version across both content and platforms. Its longevity is a function of its simplicity – the data model is limited but well-understood, implementation is consistent across platforms and compatibility issues are rare. SCORM 1.2 tracks a defined set of data points: completion status (completed or incomplete), success status (passed or failed), score and time spent. That’s essentially the full picture of what a SCORM 1.2 course can report back to the LMS.
SCORM 2004 introduced a more sophisticated data model and, more significantly, a sequencing and navigation specification that allows course designers to create branching learning paths based on learner performance. If a learner passes an assessment at a certain level, they can be routed to advanced content; if they struggle, they can be directed to remedial material. This conditional navigation capability is genuinely useful for complex learning scenarios.
The problem with SCORM 2004 is that its implementation has been inconsistent across platforms and authoring tools, leading to compatibility issues that the simplicity of SCORM 1.2 largely avoids. Many organisations and content developers have stuck with SCORM 1.2 precisely because it works reliably across a wider range of environments.
The practical implication: if you’re purchasing SCORM training courses or evaluating a platform, SCORM 1.2 compatibility is the baseline requirement. SCORM 2004 support is worth having but less universally available – and the sequencing capabilities it enables are only valuable if the content has been designed to use them.
How SCORM communication actually works
Understanding the mechanics of how a SCORM course communicates with an LMS helps explain both the capabilities and the limitations of the standard.
When a learner launches a SCORM course, the LMS opens it in a browser window or frame and initialises the SCORM API – a JavaScript object that the course content can call to read and write data. The course uses this API throughout the learning session: to retrieve information about the learner at launch, to record progress as the learner moves through the content and to commit completion and score data when the session ends.
The data that passes through this API is defined by the SCORM data model – a standardised set of fields with defined names, formats and permitted values. Completion status, success status, score, time spent, learner name, learner ID and a limited amount of interaction data are the primary fields. The LMS stores this data against the learner’s record and makes it available for reporting.
The session-based nature of this communication model is one of SCORM’s fundamental constraints. Data is recorded per session – a learner who completes half a course in one session and half in another will have two separate data records that the LMS has to reconcile. More significantly, the data model captures what happened during the course interaction but provides limited insight into the quality of that engagement.
SCORM training courses online: what SCORM cannot track
The limitations of SCORM training courses online become apparent when you consider what the standard was not designed to capture.
SCORM was conceived in an era when online learning happened in a browser, within a defined course package, on a desktop computer. The data model reflects these assumptions. It can tell you that a learner completed a course, how long they spent and whether they passed an assessment. It cannot tell you which specific content elements they engaged with most deeply, where they paused or rewound video content, how their performance on individual questions correlated with their subsequent job performance or whether they accessed any learning that happened outside the formal course environment.
For compliance training – where the primary requirement is a record that specific people completed specific training by specific dates – these limitations are largely irrelevant. SCORM does exactly what compliance tracking needs it to do.
For organisations that want richer insight into how their people actually learn – what content drives engagement, where understanding breaks down, how online learning connects to performance outcomes – SCORM’s data model is genuinely constraining.
xAPI: what it is and when it’s worth considering
xAPI – also known as Tin Can API or Experience API – was developed specifically to address the limitations of SCORM’s data model. Rather than a fixed set of predefined fields, xAPI uses a flexible statement structure based on the pattern “actor, verb, object” – “Sarah completed Module 3”, “James scored 85% on the fire safety assessment”, “the team watched the customer service video”. This structure can capture virtually any learning experience in a standardised format.
The practical implications of this flexibility are significant. xAPI can track learning that happens outside the LMS – reading an article, watching a YouTube video, completing a simulation in a separate application. It can capture granular interaction data within courses – not just whether a question was answered correctly, but how long the learner took, how many attempts they made and what answer they chose when they got it wrong. And it can store this data in a Learning Record Store that sits outside the LMS, making it accessible for analysis across multiple systems.
For most UK SMEs running standard compliance and skills training programmes, xAPI’s additional capability isn’t necessary and the complexity of implementation isn’t justified. SCORM handles the use case adequately. xAPI becomes worth considering when an organisation wants to measure learning across multiple systems and environments, when the training involves complex simulations or branching scenarios that benefit from detailed interaction tracking, or when the L&D function has the analytical capability to make use of the richer data xAPI produces.
The decision isn’t binary – many modern platforms support both standards and an organisation can use SCORM for straightforward courses while using xAPI for content where the richer data model adds genuine value.
Common SCORM problems and what causes them
SCORM’s interoperability promise – build once, run anywhere – is largely delivered in practice, but a category of compatibility issues does arise regularly enough to be worth understanding.
Completion not recording correctly is the most frequently reported SCORM problem. It usually stems from one of three causes: the course is set to mark completion on a condition that isn’t being met (viewing all slides, passing an assessment), the LMS is timing out the session before the completion data is committed, or there’s a conflict between how the authoring tool has implemented the SCORM API and how the LMS expects it to behave. The fix depends on the cause – course settings, LMS session timeout configuration or a compatibility workaround.
Score not passing to the LMS is typically a configuration issue – the course is reporting a score through the API but the LMS isn’t set to receive or display it for that particular course. Checking the course settings in both the authoring tool and the LMS usually identifies the disconnect.
Course not launching in certain browsers is increasingly common as browser security policies have tightened. SCORM courses that rely on pop-up windows or deprecated browser features may fail to launch in modern browsers without configuration changes. Content that was built several years ago and hasn’t been updated is most susceptible to this category of problem.
Suspend data limitations in SCORM 1.2 restrict the amount of learner progress data that can be stored between sessions to 4096 characters – a constraint that causes problems for complex courses that need to remember a learner’s position across multiple sessions. SCORM 2004 significantly extended this limit, which is one practical reason to consider it for longer or more complex content.
Choosing SCORM-compliant content: what to look for
When purchasing or licensing SCORM compliant training courses, a small number of checks will save significant frustration later.
Confirm which SCORM version the content uses and verify that your platform supports it. SCORM 1.2 is the safe default; SCORM 2004 requires explicit platform confirmation.
Ask the content provider whether the courses have been tested on your specific LMS. Responsible content vendors maintain compatibility testing records across major platforms and can confirm whether known issues exist.
Check how completion is triggered in the content. Courses that mark completion on final slide view behave differently from those that require assessment pass – and both behave differently from those that mark completion on time spent. Understanding the completion trigger helps set appropriate learner expectations and troubleshoot issues when completion fails to record.
Review the content’s browser and device compatibility. Content built with older authoring tools may not render correctly on mobile devices or in current browser versions. If your learners will primarily access training on mobile, this is a critical check before licensing content at scale.
The right standard for your situation
SCORM remains the most practical standard for most organisations delivering online training through an LMS. Its near-universal platform support, its reliability for compliance tracking use cases and the vast library of SCORM-compatible content available from training providers make it the sensible default for organisations that don’t have specific requirements that push them toward xAPI.
The key is understanding what SCORM does well – and where its constraints become relevant to your specific situation – so that the standard serves your training objectives rather than limiting them.
