SCO (Sharable Content Object)

What is an SCO (Sharable Content Object)?

An SCO — Sharable Content Object — is the smallest unit of content an LMS can launch and record results for within the SCORM standard. Put briefly: when your platform notes that an employee has completed something, what they completed is an SCO.

It’s a technical concept with very practical consequences for anyone managing training. The way a course is split into SCOs decides what your LMS can measure: if the whole course is a single SCO, all you’ll know is whether someone finished it; if it’s split into six, you’ll know exactly which one people get stuck on. That decision is made when the course is published, and it’s expensive to undo afterwards.

SCO vs. asset: the difference that decides everything

SCORM classifies everything inside a package into two kinds of resource: assets and SCOs. And the boundary between them comes down to one thing.

An asset is static content shown to the learner: an image, a PDF, a video, a stylesheet. It gets presented and that’s it. An SCO is also made of one or more files, but it has to be able to communicate with the LMS through the Runtime API. That ability to talk to the platform is the only thing that turns a resource into an SCO.

The consequence is very concrete: if you package a PDF as an asset, your LMS will be able to display it, but it won’t know whether anyone opened it. For there to be a record, that piece has to be an SCO.

What an SCO has to do to be an SCO

The specification imposes three obligations on any SCO. If any of them fails, the content will look the same but tracking won’t work:

1. Find the LMS API. The SCO looks for a JavaScript object in the window that contains it. It’s called API in SCORM 1.2 and API_1484_11 in SCORM 2004. If it can’t locate it, no tracking is possible.
2. Open the session before anything else. Every SCO must call Initialize — LMSInitialize in 1.2 — before sending or requesting a single piece of data.
3. Always close it. It must call Terminate — LMSFinish in 1.2 — on every exit path, including closing the tab without warning.

And there’s a rule about direction that explains a good share of tracking problems: the conversation is always started by the SCO. The LMS answers when asked, but never asks. If the SCO goes quiet, the platform has no way of finding out what happened: it simply records nothing.

One SCO or several: how to decide granularity

This is the most important practical decision around the concept, and almost nobody makes it deliberately: it gets inherited from whatever the authoring tool does by default. It’s worth deciding, because each SCO has its own record in the LMS and that defines the level of detail of every report you’ll see afterwards.

The rule of thumb is the same one that governs any learning object: an SCO should cover a single learning objective, be small enough to be reused in another course and big enough to teach something on its own. Between those two extremes, choose according to what you need to measure:

What each SCO stores, and where the limit is

Every SCO has its own set of data in the LMS, separate from the others’: completion status, score, session time, bookmark and a free field, cmi.suspend_data, where the course stores its internal state so it can resume.

Two things follow from that which surprise a lot of people the first time:

SCOs don’t talk to each other. There is no direct channel between them. If module 3 needed to know what the learner answered in module 1, the standard doesn’t provide for it: what decides the order and the conditions for moving on is the sequencing declared in the imsmanifest.xml, not the content.

The resume field has a ceiling. According to the specification reference, cmi.suspend_data allows 4,096 characters in SCORM 1.2 and 64,000 in SCORM 2004 (3rd and 4th edition). It is the most common reason a long course “loses” the point where the learner left off: the content tries to save more state than fits, and the excess is discarded without warning.

What the SCO means for training managers

You don’t need to write a line of code for this to affect your work. These are the decisions where it shows up:

• Define what you’ll be able to measure before commissioning the course. If you need to know which module people drop out at, explicitly ask for a package with one SCO per module. Asking afterwards means republishing and, on many LMS platforms, losing the history of everyone who had already started.
• Ask about the version. SCORM 1.2 is universally compatible but more limited; SCORM 2004 allows sequencing between SCOs and a richer data model. Choose based on what your platform supports, not on what’s newest.
• Check your LMS’s compatibility. Tracking only works if the platform exposes the API adapter correctly. A SCORM-compliant LMS guarantees the SCO will find something to talk to.
• Be suspicious of courses with no status. If a piece of content always shows as “not started” even though people are opening it, the most likely explanation is that it was published as an asset rather than an SCO, or that it isn’t closing the session.

EMASESA, the municipal water company of Seville, used isEazy Author to create its SCORM courses in record time and publish them straight to its LMS, with precise progress tracking for the HR team.
See how EMASESA created its e-learning courses →

Limitations of the SCO model

The SCO solved the problem it was designed for very well — content that’s portable across platforms — but it has clear boundaries:

• Isolated data. Each SCO stores its own and shares nothing with the rest, which complicates any learning path that depends on decisions made in an earlier module.
• Only inside the LMS and the browser. The SCO needs a SCORM player that exposes the API. Outside that — a native app, an in-person session, a third-party tool — there is no record.
• Granularity freezes at publication. Going from one SCO to six isn’t editing the course: it’s repackaging it and uploading it again.
• It doesn’t measure what happens outside the course. That’s what xAPI is for, which records learning experiences without depending on a browser window open against an LMS.

The SCO in practice: what the authoring tool takes care of

Day to day, whoever designs the training doesn’t build SCOs by hand: the authoring tool generates them on publication. What they do decide is the configuration, and that’s where it pays to know what you’re choosing.

isEazy Author publishes in SCORM 1.2 and SCORM 2004, generating the complete package — manifest, resources and the session start, save and close calls — with no additional technical configuration. That avoids the two most repeated failures: courses that stay “incomplete” because they never close the session, and courses that don’t resume where the learner left off because they overflow the state field.