The complaint always arrives the same way. Resume works fine in testing, works fine for the first few slides, and then one day a learner is halfway through a long course, closes it, comes back, and finds themselves at the beginning. Nothing errors. Nobody can reproduce it on slide three.
That is nearly always suspend data, and it has a hard number behind it.
What suspend data is
When a course tells the LMS where the learner got to, it does it by writing a string into a field called cmi.suspend_data. The course decides what goes in there. Storyline packs in the state of each slide, the value of every variable it needs to restore, and the learner’s progress through questions. The LMS stores the string and hands it back next time.
The catch is that the field has a size limit, and the limit is smaller than people assume.
| SCORM 1.2 | 4,096 | The one that catches everyone, and still the most common publish setting. |
| SCORM 2004, 2nd and 3rd edition | 4,000 | Slightly smaller than 1.2, which surprises people moving up. |
| SCORM 2004, 4th edition | 64,000 | Sixteen times the room, if your LMS genuinely implements it. |
Those are characters. A great many systems store the value in a database column sized in bytes, and for plain English the two numbers are the same, so nobody notices. Add accented characters, curly quotes or an emoji and they diverge: a course that resumes perfectly in English can quietly stop saving in French.
How it fails, which is the confusing part
Most systems do not raise an error when the string is too long. They truncate it, or reject that one call and carry on. The course then reads back a string it cannot make sense of and starts from the beginning. So the symptoms are:
- resume works early in the course and stops working later on
- progress resets for some learners and not others
- quiz answers are lost between sessions
- it is fine in SCORM Cloud and broken in the LMS, or the reverse, since systems enforce the limit differently
Six ways to get under the line
- Publish for SCORM 2004 4th edition if the LMS supports it properly. Sixteen times the room solves the problem outright, and the caveat is real: some systems claim 4th edition and behave like 1.2.
- Split the course. Two modules of thirty slides each have their own allowance. This is the fix that always works, and it is usually better for the learner as well.
- Track fewer slides. Storyline stores state for slides it has to restore. A course that does not need every layer and every visited state remembered is a smaller string.
- Use fewer variables, and shorter ones. Text variables holding sentences are expensive. Numbers and booleans are cheap.
- Reconsider resume at all. A fifteen-minute course does not need it. Prompting to resume is a setting, and switching it off is a legitimate design decision rather than a defeat.
- Check before release, not after. Measure it on the longest path through the course: every slide visited, every question answered. That is the worst case, and the worst case is what your most conscientious learner will produce.
Related failures that look the same
Not every resume problem is the size limit. Before you rebuild anything, rule out the neighbors:
cmi.core.lesson_locationhas its own limit, 255 characters under SCORM 1.2, and storing a path rather than an identifier overflows it easily.- The LMS may not be committing data at all, in which case nothing resumes from the very first slide. The LMS Error Decoder translates the codes that show up when that is happening.
- Learners launching the course from a copied link rather than through the LMS have no session to save into. The upload and tracking guide covers the rest of that family.