What breaks between your storyboard and the LMS

The course was approved. The SMEs signed off. The build looks right in preview. Then it goes into the LMS and learners start reporting that their progress does not save, or that the course marks itself complete the moment it opens, or that it never marks complete at all.

This failure mode is common enough to be predictable, and it has almost nothing to do with the quality of the content. It is a handoff problem. The packaging standard, the LMS configuration, and the authoring tool's defaults all have opinions about what "done" means, and they frequently disagree.

Pick the standard for the right reason

Most teams inherit their packaging standard rather than choose it. It is worth knowing what each one actually buys you.

SCORM 1.2 is the oldest and still the most widely supported. It has one status field covering both completion and pass or fail, which means you cannot express "the learner finished the course but failed the assessment" as two separate facts. Its bookmarking storage is capped at 4096 characters, which is small enough that a long branching course can silently exceed it and lose the learner's place.

SCORM 2004 separates completion from success, so "finished but failed" is expressible. Its bookmarking storage is far larger, and it supports sequencing rules. It is also less uniformly implemented, and the sequencing features in particular vary between LMS vendors.

xAPI sends statements to a learning record store rather than reporting to the LMS through a package wrapper. It captures far more than completion, including activity outside the LMS entirely. It also requires an LRS and does not, by itself, solve LMS launch and tracking.

cmi5 is the bridge. It defines how an LMS launches content and how that content reports through xAPI, which gets you xAPI's data model with the launch and completion semantics of a SCORM-style package.

If you have no constraint pushing you elsewhere, SCORM 2004 remains the sane default for LMS-delivered training, and cmi5 is the one to move to when you need the data.

The five failures that account for most launch-day tickets

Completion criteria that nobody defined. The authoring tool has a default. The LMS has a setting. The stakeholder has an expectation. These are three different things, and the time to reconcile them is before publish. Write down the completion rule as a sentence during the storyboard phase: "complete when the learner views all slides and scores 80 percent or higher." Then verify the package and the LMS course setting both implement that sentence.

Suspend data overflow. If you are on SCORM 1.2 with a long course, extensive branching, or a lot of interaction state, you can exceed 4096 characters. The failure is quiet: bookmarking simply stops working correctly, usually for the learners furthest into the course, which is the group least likely to file a helpful bug report.

Assuming the LMS reads what you send. Sending a score is not the same as the LMS recording it, which is not the same as the LMS displaying it in the report the stakeholder actually opens. Each link in that chain is a separate configuration. Verify the specific report your stakeholder will look at, not just that the data left the course.

Mixed content and embeds. An LMS served over HTTPS will block an asset loaded over HTTP, and the block is often silent. Video embeds, font CDNs, and analytics scripts are the usual offenders. This one is easy to miss in preview, because preview is not running inside the LMS frame.

Nobody tested on the actual LMS. Preview in the authoring tool exercises none of the integration. The only test that means anything is a real upload into a real course shell, launched as a real enrolled learner, with a second attempt to confirm resume behavior.

A pre-publish checklist

Run this before the package goes to the LMS admin, not after:

1. Write the completion rule as one sentence and confirm the package implements it.
2. Confirm the LMS course setting matches that sentence.
3. Launch as an enrolled test learner, not as an admin. Admin accounts routinely bypass tracking.
4. Exit halfway, relaunch, and confirm the bookmark restored.
5. Complete the course and confirm the status changed in the LMS report your stakeholder will read.
6. Fail the assessment deliberately and confirm the status reflects it correctly.
7. Check the browser console for blocked mixed content during a real launch.
8. Test on the devices your learners actually use, including whatever locked-down corporate browser your field team is issued.

Steps 5 and 6 are the ones teams skip, and between them they account for most of the "the course says complete but the report says incomplete" tickets.

Version the package, not just the content

When a course is republished mid-rollout, learners in progress can lose their place or have their completion invalidated, depending on how the LMS handles the update. Treat a republish during an active rollout as a decision requiring sign-off, not a routine content push.

That means the package needs a version, and the version needs to be traceable back to the content state that produced it. If you cannot answer "which storyboard version produced the SCORM file currently live in the LMS", the first serious content dispute will cost you a day of archaeology.

Where the tooling helps

Rough Cut exports from a canonical content model rather than from whatever the authoring tool last saved, and the targets are SCORM 1.2, SCORM 2004, xAPI, cmi5, PowerPoint, and a Storyline handoff. Exporting from one model means the same approved content state produces every target, and the export is tied to the version that produced it.

That does not stop an LMS from being configured incorrectly, and no export format will. What it does is remove the class of problem where the package and the approved content have quietly drifted apart, so when something does break on launch day you are debugging one thing instead of two.