SCORM 2004 Sequencing and Navigation: The Definitive Technical Guide for LMS Admins and Developers (2026)

If your multi-SCO course is looping back to the first module after completion, silently ignoring rollup rules, or reporting completed/failed as completed/unknown in your LMS, this guide addresses those failure modes directly. They almost always trace back to a misunderstanding of the SCORM 2004 Sequencing and Navigation specification , specifically the interaction between the Activity Tree, the Sequencing Definition Model, and the LMS’s implementation of the 18 pseudo-code algorithms defined in SCORM 2004 4th Edition Sequencing and Navigation (SN) Version 1.1, published March 31, 2009 by the Advanced Distributed Learning (ADL) Initiative.

The 4th Edition introduced four material changes over 3rd Edition: a Jump navigation request, completion threshold controls via cmi.progress_measure, shared data buckets between SCOs (adlcp:data), and expanded global objective data. If your implementation predates 4th Edition, note that 1st Edition sequencing had fundamental un-implementable defects and should not be deployed; Rustici Software explicitly advises against it.

Unless you are targeting Open edX, where sequencing support is minimal, the LMS platforms most commonly deployed in enterprise environments now support 4th Edition. The practical gap is not LMS support , it is authoring-tool output and manifest configuration errors.

SCORM 2004 4th Edition Sequencing and Navigation: Architecture

The Activity Tree and Tracking Model

Every SCORM 2004 package describes its content structure as a hierarchical Activity Tree in imsmanifest.xml. Each node is an activity , either a leaf (associated with a SCO or asset) or a cluster (an aggregation of child activities). The LMS maintains a Tracking Model for each activity that mirrors the runtime data model: Objective Satisfaction Status, Completion Status, Attempt Count, Score, and Progress Measure. When a SCO exits, its runtime data is transferred into the tracking model and the Overall Rollup Process [RB.1.5] propagates aggregated status up the tree.

The Sequencing Loop

Each user action (Continue, Previous, Choice, Exit, Abandon, Jump) generates a Navigation Request, which the LMS processes through a deterministic set of 18 pseudo-code algorithms. The critical path for a Continue request is:

1. Navigation Request Process, validates the request and maps it to a Sequencing Request (e.g., Continue → Flow)
2. Termination Request Process [TB.2.3], ends the current SCO attempt; triggers Sequencing Exit Action Rules [TB.2.1] and Post-Condition Rules [TB.2.2]
3. Overall Rollup Process [RB.1.5], consolidates completion/satisfaction from children up the tree
4. Sequencing Request Process [SB.2.12], determines the next valid activity for delivery
5. Delivery Request Process [DB.1.1], validates the candidate activity is deliverable (not disabled, within attempt limits, not already satisfied if pre-conditions exclude it)

Any step that returns an exception aborts the chain and the learner sees no navigation. This is why a misconfigured sequencing rule can produce a “silent dead-end” with no error message, the spec-compliant LMS is doing exactly what the manifest instructs.

Sequencing Definition Model: Core Constructs

The <imsss:sequencing> element in the manifest applies to each activity independently. The seven rule categories are:

• Sequencing Control Modes, six boolean attributes governing TOC navigation, flow, and forward-only enforcement (see table below)
• Sequencing Rules, pre-, post-, and exit-condition rules evaluating objective/completion/progress state to Skip, Disabled, Stop Forward Traversal, or Retry an activity
• Rollup Rules, if-then conditions determining how child status aggregates to the parent cluster
• Rollup Controls, per-activity participation flags (always / ifNotSuspended / ifAttempted / ifNotSkipped) for both satisfaction and completion rollup
• Objectives, primary (rollup) and auxiliary objectives; global objectives shared via adlcp:map across SCOs and optionally across sessions
• Limit Conditions, attempt count cap (attemptLimit), absolute duration, and experienced duration limits per activity
• Randomization / Selection Controls, random subset selection (selectCount) and shuffle timing (onEachNewAttempt vs once)

Control Mode Attribute Reference (imsss:controlMode)

Annotated imsmanifest.xml Sequencing Block

The following is a production-realistic sequencing block for a three-module course with a prerequisite gate, attempt limit, and rollup rule:

<!– Organization root: flow enabled, free choice disabled for enforcement –>
<item identifier=”ROOT”>
<imsss:sequencing>
<imsss:controlMode choice=”false” flow=”true” forwardOnly=”true”/>
<!– Rollup: parent is ‘completed’ when ALL children are completed –>
<imsss:rollupRules rollupObjectiveSatisfied=”true”
rollupProgressCompletion=”true”>
<imsss:rollupRule childActivitySet=”all”>
<imsss:rollupConditions operator=”and”>
<imsss:rollupCondition condition=”completed”/>
</imsss:rollupConditions>
<imsss:rollupAction action=”completed”/>
</imsss:rollupRule>
</imsss:rollupRules>
</imsss:sequencing>

<!– Module 1: max 2 attempts; satisfied status shared globally –>
<item identifier=”MOD1″ identifierref=”RES_MOD1″>
<imsss:sequencing>
<imsss:limitConditions attemptLimit=”2″/>
<imsss:objectives>
<imsss:primaryObjective objectiveID=”OBJ_MOD1″
satisfiedByMeasure=”true”>
<imsss:minNormalizedMeasure>0.8</imsss:minNormalizedMeasure>
</imsss:primaryObjective>
</imsss:objectives>
</imsss:sequencing>
</item>

<!– Module 2: gated on MOD1 satisfaction via pre-condition rule –>
<item identifier=”MOD2″ identifierref=”RES_MOD2″>
<imsss:sequencing>
<imsss:sequencingRules>
<imsss:preConditionRule>
<imsss:ruleConditions operator=”and”>
<!– Disable MOD2 until MOD1 objective is satisfied –>
<imsss:ruleCondition referencedObjective=”OBJ_MOD1″
operator=”not” condition=”objectiveSatisfied”/>
</imsss:ruleConditions>
<imsss:ruleAction action=”disabled”/>
</imsss:preConditionRule>
</imsss:sequencingRules>
</imsss:sequencing>
</item>
</item>

SCORM 2004 4th Edition LMS Compatibility Matrix (2026)

“Partial” indicates the platform supports the feature but with known gaps or configuration-dependent behavior. “✗” indicates no functional support per vendor documentation or community-confirmed testing. All data cross-referenced against vendor documentation and ADL Test Suite compliance reports where available.

Critical notes: Moodle’s partial Sequencing Rules support traces to known bugs in sequencinglib.php (MDL-28805 and dependencies), where adl.nav.request calls from within a SCO can re-launch the current activity instead of advancing. Cornerstone’s documented non-support of Jump navigation should be verified on each environment version; they do not expose this in standard certification statements. Open edX’s SCORM XBlock provides minimal SN support , and does not deploy complex sequencing on Open edX without a dedicated SCORM Cloud proxy layer

Implementation Steps: Configuring Sequencing for Specific Authoring and Delivery Contexts

Articulate Storyline 360

• Storyline is published as SCORM 2004 4th Edition by default. Its sequencing output is minimal, it wraps the course as a single logical SCO even in multi-scene projects, meaning the LMS SN spec is largely bypassed, and completion is driven by cmi.completion_status set by Storyline’s internal JavaScript.
• To leverage LMS-side sequencing across discrete SCOs, you must publish each scene/module as a separate package and construct the activity tree and <imsss:sequencing> block manually in imsmanifest.xml before re-zipping. Storyline’s native multi-SCO output does not do this.
• For cmi.progress_measure (4th Edition completion threshold), Storyline supports it via the “Complete/Incomplete” tracking option tied to quiz score, but does not expose the XML attribute directly. You must post-process the manifest.

Adobe Captivate (2024+)

Captivate’s SCORM 2004 4th Edition output correctly populates completionThreshold and supports branch-aware sequencing when using question pools with remediation loops.

For branching scenarios, Captivate’s “branching view” maps directly to activity clusters. However, the generated <imsss:rollupRules> defaults to childActivitySet=”all” with a completed condition, verifying this matches your completion intent (all vs. any child).

Known issue: Captivate’s TOC passes adl.nav.request values via its internal JavaScript rather than through the standard navigation model in some versions. Test with ADL Test Suite or SCORM Cloud before deployment to any LMS other than those using Rustici Engine.

Hand-authoring / Custom SCO Development

• Namespace declaration in imsmanifest.xml is mandatory:

xmlns:imsss=”http://www.imsglobal.org/xsd/imsss”
xmlns:adlseq=”http://www.adlnet.org/xsd/adlseq_v1p3″
xmlns:adlnav=”http://www.adlnet.org/xsd/adlnav_v1p3″
xmlns:adlcp=”http://www.adlnet.org/xsd/adlcp_v1p3″

• Use adl.nav.request (not a page redirect) for all in-SCO navigation requests. Valid values: {continue}, {previous}, {choice|target=ITEM_ID}, {jump|target=ITEM_ID} (4th Edition only), {exit}, {exitAll}, {abandon}, {abandonAll}, {suspendAll}.
• Set adl.nav.request before calling Terminate(). Setting it after Terminate() is a sequencing timing bug that LMSs may silently discard.
• For the Jump request (4th Edition): the LMS resolves the target activity ID against the Activity Tree but ignores controlMode constraints during resolution , this is intentional per spec. If your LMS does not support Jump (Cornerstone, Docebo), fall back to {choice} with appropriate choice=”true” in the cluster’s controlMode.

Common SCORM 2004 Sequencing Issues and Specific Fixes

1. Course Restarts From Module 1 After Completion (Flow Loop)

Symptom: Learner completes the final SCO, clicks Continue, and the LMS launches Module 1 again.

Root cause: The post-condition rules or rollup rules on the root cluster evaluate to a retry action , typically because rollup has not resolved the parent to completed before the Continue request is processed. The sequencing loop then finds no valid forward activity and wraps back to the first activity.

• Fix: Confirm the root aggregation’s rollup rules cover all leaf states. Add an explicit post-condition rule on the root: if objectiveStatusKnown AND completed, action = exitParent. Verify via SCORM Cloud’s sequencing debugger (enable Sequencing Audit in the course settings).
• Also check: useCurrentAttemptProgressInfo defaults to TRUE , if children are being attempted across multiple sessions, prior attempt data may not contribute to current rollup without explicitly setting it to FALSE.

2. Module 2 Remains Disabled Even After Module 1 Pass (Pre-condition Gate Failure)

Symptom: Pre-condition gate using objectiveSatisfied on an upstream SCO’s objective keeps Module 2 disabled after Module 1 is passed.

Root cause: The SCO is setting cmi.success_status = passed at runtime, but the sequencing block’s primaryObjective is configured with satisfiedByMeasure=”true” and a minNormalizedMeasure that the SCO’s reported score does not meet , OR the objective ID in the manifest does not match the cmi.objectives.0.id set by the SCO at runtime.

• Fix: Run SCORM Cloud in debug mode. Check the objective tracking data: the Objective Tracking panel shows the satisfaction state the LMS computed from rollup vs. what the SCO reported. Mismatched objectiveID values (case-sensitive string compare) are the most frequent cause. Also confirm satisfiedByMeasure intent , if the SCO explicitly sets cmi.success_status, set satisfiedByMeasure=”false” and remove the measure threshold to avoid conflict.

3. adl.nav.request = “{continue}” Has No Effect

Symptom: SCO calls adl.nav.request = “{continue}” before Terminate() but the LMS does not advance; the TOC remains on the current SCO.

Root cause: The cluster containing this SCO has flow=”false” (the default). With flow disabled, Continue/Previous navigation requests are invalid for the cluster , the LMS evaluates them and returns an exception that produces no navigation. This is spec-compliant behavior.

• Fix: Set flow=”true” on the parent cluster. Alternatively, if free-choice navigation is intended, ensure choice=”true” and use {choice|target=ITEM_ID} instead of {continue}.
• Moodle-specific: Even with flow=”true”, Moodle’s sequencinglib.php has documented bugs where adl.nav.request from a SCO re-launches the current item. Test against MDL-28805 patch status for your Moodle version.

4. Completion Status Correct per SCO, Wrong at Course Level (Rollup Mismatch)

Symptom: Individual SCOs show completed in the LMS, but the course-level record shows incomplete or unknown.

Root cause: Rollup rules on the parent cluster are not matching the children’s actual state. Common causes: (a) childActivitySet is set to “all” but one leaf is suspended rather than completed; (b) rollup consideration for a child is ifNotSuspended and a learner paused mid-course; (c) authoring tool output includes a rollupRule with condition=”satisfied” when the SCO only ever sets cmi.completion_status, never cmi.success_status.

• Fix: Review generated imsmanifest.xml rollup conditions against the actual runtime data model elements your SCOs set. The separation of completion status and success status in SCORM 2004 means rollup rules must explicitly target the correct status dimension. Per ADL documentation, completed condition evaluates Completion Status; satisfied evaluates Objective Satisfaction Status, conflating them is the most common authoring tool output error.

5. Jump Navigation Ignored on Certain LMS Platforms

Symptom: SCO calls adl.nav.request = “{jump|target=ITEM_ID}” (4th Edition only) and nothing happens, or the SCO relaunches.

Root cause: The LMS does not support Jump navigation (Cornerstone, Docebo, some SAP SuccessFactors versions) or the target ITEM_ID does not match the identifier attribute of the target <item> in the manifest (case-sensitive).

• Fix: Before deploying Jump-dependent content, validate against the compatibility matrix above. For unsupported platforms, replace Jump with Choice navigation (requires choice=”true” on the cluster). For ID mismatches, grep the manifest for the exact identifier string , authoring tools sometimes normalize identifiers on export.

6. Shared Data Between SCOs (adlcp:data) Not Persisting Across Sessions

Symptom: Shared data buckets set by SCO A are not available to SCO B on a subsequent session, despite using adlcp:data correctly.

Root cause: The adlcp:data / adlcp:map mechanism (introduced in 4th Edition) depends on the LMS persisting shared data buckets to server-side storage between attempts. Not all LMS implementations persist these across sessions , some treat the buckets as attempt-scoped only. This is an LMS conformance issue, not a content issue.

• Fix: Test with SCORM Cloud, which correctly implements cross-session persistence for adlcp:data. If SCORM Cloud works and your LMS does not, file a support ticket citing the ADL SN 4th Edition specification, Section 3.3.2 (Shared Data Between SCOs). As a workaround, use global objectives (adlseq:objectives with readSatisfiedStatus=”true” and writeSatisfiedStatus=”true”) to pass boolean state between SCOs, global objectives are more widely implemented than shared data buckets.