Why Your SCORM Course Isn't Tracking Completions: The 7 Real Causes

A learner clicks through every slide, passes the quiz, closes the window — and the LMS says incomplete. If you run compliance training, that's not a cosmetic bug. It's an audit finding waiting to happen.

We repair SCORM tracking for a living, and after enough of these you notice something: it's almost never a mysterious LMS bug. It's one of seven specific, findable, fixable causes. This guide covers all seven with enough detail that you can fix most of them yourself. That's deliberate. If you get stuck, we're here; if you don't, you just saved a few hundred dollars.

First, understand what "completion" actually is

A SCORM package doesn't tell the LMS "the learner finished." It makes JavaScript calls against an API object the LMS exposes in the browser — LMSSetValue("cmi.core.lesson_status", "completed") in SCORM 1.2, or SetValue("cmi.completion_status", "completed") in SCORM 2004. The LMS writes those values to its database, and reports are built from those rows. In Moodle™ that table is mdl_scorm_scoes_track (through 4.2) or mdl_scorm_scoes_value joined to mdl_scorm_element (4.3 and later).

So a "completion not tracking" problem is always one of three breakages: the call was never made, the call was made but rejected or mistranslated, or the value landed but the report interprets it differently than you expect. The seven causes below are just the specific ways each of those happens.

The two-minute triage

Before anything else, open the course, press F12, select the frame that contains the actual course content (not the LMS shell) in the console's frame picker, and paste:

(function () {
  var w = window;
  for (var i = 0; i < 10; i++) {
    if (w.API) return "SCORM 1.2 API found";
    if (w.API_1484_11) return "SCORM 2004 API found";
    if (w.parent === w) break;
    w = w.parent;
  }
  return "No API found";
})();

"No API found" sends you straight to cause 5. An API that's present but the wrong version is cause 1 or 2. If the API is there and correct, the problem is in what's being sent or how it's being scored — causes 3, 4, 6, or 7 — and the database tells you which. In Moodle:

SELECT element, value, timemodified
FROM mdl_scorm_scoes_track
WHERE userid = :userid AND scormid = :scormid
ORDER BY timemodified;

Those rows are the ground truth. Everything below comes back to them.

Get a free SCORM tracking diagnosis

Rather have us look? Send the package or a test login and we'll tell you which of the seven it is — free, and we reply within 1 business hour. Repairs are $350 flat if you want us to finish the job.

1. The version mismatch: your manifest says one thing, your content says another

Every SCORM zip has an imsmanifest.xml at its root, and the LMS believes whatever it says. Open it and find the metadata block:

ADL SCORM
1.2

versus, for 2004:

2004 3rd Edition

A second tell: SCORM 1.2 resources use adlcp:scormtype="sco" (lowercase t), 2004 uses adlcp:scormType="sco". Yes, the capital T matters. Welcome to SCORM.

The failure mode: someone hand-assembled or "converted" a package, the manifest declares 1.2, so the LMS exposes window.API — but the content's runtime JavaScript is 2004 code hunting for window.API_1484_11. It finds nothing, gives up, and not one row is ever written. The course usually still plays, which is what makes this one so sneaky.

Confirm it

The triage snippet reports which API the LMS exposed. Then check the content's own launch file (usually index_lms.html or similar) or the console errors — a 2004 package failing on a 1.2 adapter typically logs its own "API not found" complaint. Zero rows in mdl_scorm_scoes_track for a course the learner demonstrably opened is the database signature.

The fix

Re-export from the authoring tool with the version set correctly, or edit the manifest to declare the version the content actually speaks. Don't try to translate the runtime calls by hand unless you enjoy pain — the data models don't map one-to-one, which brings us to cause 2.

2. lesson_status vs completion_status: one field became three and nobody told your report

SCORM 1.2 has a single status field, cmi.core.lesson_status, with six legal values: passed, completed, failed, incomplete, browsed, not attempted. SCORM 2004 split it into two independent fields: cmi.completion_status (did they finish?) and cmi.success_status (did they pass?). A learner can be completed + failed at the same time in 2004. In 1.2 that state literally cannot be expressed.

The confusion cuts both ways. A 2004 package that only ever sets completion_status looks unfinished to any report keyed on success. A converted package running as 2004 that still calls SetValue("cmi.core.lesson_status", ...) gets error 401 (undefined data model element) on every attempt — the call fails quietly and status never moves.

Confirm it

Look at the element names in your tracking rows. If you see cmi.completion_status rows but your report or completion rule is looking for passed/failed, that's it. If you see a score but no status element of either flavor, the package isn't sending one — skip ahead to cause 7.

The fix

Align the three layers: what the package sends, what the LMS stores, and what the report reads. In Moodle, the activity completion setting "Require status" lets you pick Passed and/or Completed — checking both covers packages that send either. If the package sends nothing useful, the fix is in the authoring tool's reporting settings (cause 7), not the LMS.

5. API discovery fails in nested iframes and popups

SCORM content finds the LMS API by climbing the browser's window tree — the standard ADL findAPI routine checks window.parent, then the parent's parent, and gives up after 7 levels (it also checks window.opener for popup launches). This worked fine in 2004, when a course sat one frame below the LMS. It breaks in three modern ways:

• Too many layers. An LMS theme wrapper, an embedded player, a portal that iframes the whole LMS — stack enough frames and the content is more than 7 hops from the API. The search gives up.
• Cross-origin frames. If the package is served from a different domain than the LMS shell (a CDN, a separate content server), the browser throws a SecurityError the moment findAPI touches window.parent. The API might be one frame away; the content is forbidden from looking.
• Severed popups. A course that opens itself in a new window depends on window.opener — which modern browsers and rel="noopener" policies increasingly null out.

Confirm it

This is the cause when the triage snippet says "No API found," when learners see an "Unable to acquire LMS API adapter" alert, or when the console shows SecurityError / cross-origin frame access errors. The database signature is stark: zero rows, every learner, every attempt. And the package will work flawlessly when you upload it to SCORM Cloud — because the problem was never the package.

The fix

Serve the content from the same origin as the LMS. Flatten the frame stack: in Moodle's SCORM activity, set Display to "Current window" rather than "New window," and stop iframing the LMS inside another portal if you can avoid it. If the content insists on opening its own popup, reconfigure that in the authoring tool's player settings instead. Hosting setup is exactly the kind of thing our managed Moodle hosting gets right by default, for what it's worth.

6. The LMS grading method is counting something your package never sends

Moodle's SCORM activity has four grading methods: Learning objects, Highest grade, Average grade, and Sum grade. "Learning objects" doesn't read scores at all — it counts how many SCOs in the package reported a completed or passed status. For a package that reports a score but never sets a status Moodle counts (see causes 2 and 7), that count is zero. Grade: 0. Forever.

On its own that's a gradebook oddity. It becomes a completion bug when activity completion is set to "Require grade" — the completion rule waits on a grade that can never arrive, so the activity never ticks, course completion never fires, and the certificate downstream never issues. The tracking data, meanwhile, looks fine. Most shops stare at the package for a day before anyone opens the grading dropdown.

Confirm it

Status rows present and correct in the tracking table, but the gradebook shows 0 and the completion checkbox stays empty. That combination is this cause, nearly every time.

The fix

Set the grading method to "Highest grade" for scored content, and drive completion from "Require status: Passed or Completed" instead of the grade. Re-grading existing attempts in Moodle recalculates from the stored tracks, so historical learners get credited too — no one has to retake anything.

Questions we get asked about SCORM completion tracking