Two questions, two fields
A finished course answers two questions that have nothing to do with each other. Did the learner get to the end? And did they meet the standard? SCORM completion status vs success status is exactly that split: SCORM 2004 gives each question its own field, and SCORM 1.2 gives you one field for both.
| Field | Question it answers | Allowed values |
|---|---|---|
cmi.completion_status | Did they get to the end? | completed, incomplete, not attempted, unknown |
cmi.success_status | Did they meet the standard? | passed, failed, unknown |
They are independent. All four combinations are legal and each means something real: completed and passed (finished, met the bar); completed and failed (finished, did not meet the bar); incomplete and passed (passed the assessment early, has not seen everything); incomplete with success unknown (still working).
There is a third field that ties them together. cmi.scaled_passing_score, set from the manifest, tells the content the threshold as a value between −1 and 1. If your content writes cmi.score.scaled and the LMS knows the threshold, some platforms will derive success_status themselves — but you should never rely on that. Write the status explicitly.
How SCORM 1.2 collapses them
SCORM 1.2 has one field, cmi.core.lesson_status, and it holds exactly one of: passed, failed, completed, incomplete, browsed, not attempted. Notice that the list mixes both questions together. passed and failed answer the assessment question; completed and incomplete answer the progress question; and you get to store one of them.
So a 1.2 course with an assessment has to choose what to say. Write passed and you have reported the outcome but told the LMS nothing about whether the learner reached the end. Write completed and you have reported progress and thrown away the assessment result. There is no third option, and every 1.2 authoring tool has quietly made this choice on your behalf — usually passed/failed when a quiz exists, completed otherwise.
failed in 1.2. Some LMS reports treat any terminal status as "done" and show the course complete; others treat only passed and completed as done and show it outstanding. Both readings are defensible from a single field, which is the whole problem.Completed but failed
The combination that only 2004 can express is the one that matters most in compliance work. Someone sat through the entire annual training and scored 60% on an assessment with a 80% bar. Did they complete the training? Yes — demonstrably, every screen. Did they pass? No.
Under 2004 that is two clean values and two clean report columns. Under 1.2 it is one value, and whichever you choose is misleading to somebody: report failed and the completion report says they never did the training, which is false and generates a chase-up they do not deserve; report completed and the assessment result vanishes, which is the finding an auditor actually asked for.
The inverse case is rarer but real: a learner who takes a pre-test, passes it, and is excused the rest. passed with incomplete describes that exactly. In 1.2 it cannot be said at all.
How the LMS rolls them up
The two fields do not just sit in a report — in SCORM 2004 they drive sequencing. Rollup rules in the manifest read child activities' statuses and derive the parent's, and the rules for the two fields are separate. An objective's satisfied state comes from success; its completed state comes from completion. A rule like "the module is satisfied when all children are satisfied" is not the same rule as "the module is complete when all children are complete", and a well-built package usually declares both.
That separation is what makes prerequisites work properly. "You may start module 3 once module 2 is satisfied" is a different gate from "once module 2 is complete", and 2004 lets you say which you mean. SCORM 2004 sequencing covers the rule model and the parts platforms most often skip.
One ordering rule matters regardless of version, and it causes real data loss: write the score before the status, and commit immediately after. Platforms that evaluate a mastery score at the moment status arrives need the number to already be there. Writing status first and score second means the evaluation runs against an empty score. That, and a missing commit afterwards, are two of the causes in why courses lose completions.
Mapping between 1.2 and 2004
Converting a package between versions means collapsing or expanding the status, and both directions lose something. Going down from 2004 to 1.2:
| 2004 completion | 2004 success | Best 1.2 lesson_status | Lost |
|---|---|---|---|
completed | passed | passed | Nothing meaningful |
completed | failed | failed | That they finished |
completed | unknown | completed | Nothing — no assessment existed |
incomplete | passed | passed | That they have content left |
incomplete | unknown | incomplete | Nothing |
Going up from 1.2 to 2004 is guesswork, because one value cannot become two. passed becomes success_status: passed and — by convention, not by evidence — completion_status: completed. failed becomes failed plus completed, on the reasoning that you have to reach an assessment to fail it. completed becomes completed with success unknown. browsed, which 2004 dropped, has no equivalent at all.
Any migration that carries historical records across versions inherits those assumptions. It is worth writing down which convention you used, because a year later nobody remembers why every legacy record is marked complete. Version changes are one of the quieter risks in migrating an LMS without breaking your SCORM courses.
When you must use 2004
Three cases where the single field is not enough and the version choice is made for you:
- Assessed compliance training. Anyone who has to evidence both attendance and result needs both fields. This is the common case, and it is why regulated industries standardised on 2004 long before anyone else did.
- A pass threshold the LMS enforces. If the platform is meant to compare a scaled score against a mastery score and set success itself, it needs
cmi.score.scaledandcmi.scaled_passing_score— neither of which exists in 1.2. - Prerequisites gated on passing rather than finishing. Rollup that distinguishes satisfied from completed requires the two fields to be distinct.
Outside those, 1.2 is usually the safer package, for the reasons in which SCORM version should I use. The status model is the main thing you give up by choosing it — so if the course is assessed and the result matters, that is the moment the decision flips.
Where SCORM Central fits
SCORM Central converts files you already have — PDF, PowerPoint, Word, or video — into SCORM 1.2, SCORM 2004, cmi5, or xAPI, and shows you the manifest, the full runtime log, and a conformance report on every build, so you can see exactly what a package will report before an LMS does. See how it works, or start with one file.