What Is SCORM Dispatch? A Practical Guide for Training Providers

You have a course your customers want. There is just one catch: they want learners to launch it from their own LMS.

That is a reasonable request. Their LMS already has the learner roster, assignments, reminders, manager reports, and compliance transcript. Asking everyone to create another account in another portal adds friction, support tickets, and one more password to forget.

The old answer was to send the customer your complete SCORM ZIP file. It works, but it also means handing over a copy of the course. Once that file leaves your system, it is difficult to know how many people use it, whether the customer still has permission to use it, or which version is actually running.

SCORM dispatch offers a better arrangement: the customer launches the course from their LMS, while you continue to host and control the course itself.

That distinction matters for training resellers, certification programs, associations, and compliance-content providers. It lets the client keep its LMS workflow without forcing the provider to give up the content, the operating data, or the ability to end access.

The Short Version

SCORM dispatch is a hosted course-delivery model built on top of the normal SCORM launch and tracking workflow.

Instead of giving a client the complete course package, the provider gives them a small SCORM package that acts as a secure launcher. The client imports it into their LMS just like any other SCORM course. When a learner opens it, the actual course runs from the provider's platform.

The client LMS still receives the result it needs:

• completion or incomplete status
• passed or failed status, when applicable
• an overall score
• enough resume information to reopen the hosted attempt

Meanwhile, the provider keeps the detailed course state, source content, activity data, and access policy.

One useful clarification: SCORM dispatch is not a separate edition of SCORM. It is a delivery approach. The launcher can use SCORM 1.2 or SCORM 2004 depending on what the receiving LMS supports.

Why Ordinary SCORM File Sharing Becomes a Problem

Sending a full SCORM package feels simple because it is simple. The customer uploads the file, assigns it, and runs it without depending on your platform.

The trouble starts after the handoff.

Imagine you license a safety course to 20 client organizations. Each client receives a ZIP file. Six months later, you correct a procedure, replace a video, and update the final assessment. You now have 20 separate copies in the wild, and no reliable way to know which client installed which revision.

There are other questions too:

• Did the client license 200 seats and use 2,000?
• Is a course still launching after the contract expired?
• Did learners fail because of the course, the client LMS, or a bad upload?
• Can your support team see where a learner stopped?
• If the client says completions are missing, do you have any evidence beyond their screenshot?
• If your source package contains valuable intellectual property, can you prevent it from being copied again?

A SCORM file was designed to be portable. That is one of the format's strengths. But portability and commercial control are not the same thing.

Dispatch is useful when you need both.

How a Dispatch Launch Works

The learner experience should feel ordinary.

1. The training provider creates a hosted dispatch export for a published course.
2. The client imports the small SCORM package into its LMS.
3. The client assigns that course using its normal enrollment process.
4. The learner launches from the client LMS.
5. The dispatch package passes the launch and learner context to the provider's hosted player.
6. The provider runs the real course, saves the detailed attempt, and returns the course-level result to the client LMS.

The client does not need to understand the provider's internal activity tree. As far as the client LMS is concerned, it launched one course and received one result.

That separation is important. A hosted course might contain eight activities, several quizzes, a video, and a remediation path. Trying to make the external LMS manage every internal transition would create two competing systems of record. The provider's sequencing engine should manage the course. The client LMS should manage the client's enrollment and transcript.

Your LMS Should Support Dispatch If You Share Courses With Clients

Plenty of LMS buying checklists ask whether a platform can import SCORM. That is only half the question for a training reseller.

If course distribution is part of your business, ask whether the LMS can export a hosted dispatch package too.

Without that capability, you are usually left with one of three compromises:

• give every client the complete source package
• require every learner to use your portal instead of the client's LMS
• build and maintain a custom integration for each customer

None is automatically wrong. Some customers really do need an offline copy. Some training programs are better served in the provider's branded portal. Large clients may justify a direct integration.

But dispatch covers the common middle ground: the customer wants training inside its LMS, and the provider wants to operate the course as a hosted service.

For a reseller, that is not a niche technical feature. It affects how easily you can sell, support, renew, and protect the course.

The Client Needs a Transcript, but You Still Need the Data

The phrase "the data" can become vague very quickly, so it helps to split it into two layers.

What the client LMS needs

The client normally needs enough information to run its own training operation. That means knowing whether the learner completed the course, whether they passed, the final score, and whether an attempt can be resumed.

Those values feed assignments, manager dashboards, compliance reports, and downstream HR systems. A dispatch implementation that launches content but never produces a trustworthy transcript is not doing the job.

What the training provider needs

The provider needs enough detail to operate and support the course. Depending on the content, that can include:

• which internal activity the learner reached
• completion and success for each required activity
• quiz attempts and item-level results for native assessments
• video progress or active viewing time
• SCORM runtime calls and errors
• sequencing decisions and remediation paths
• the exact course and resource versions used

This is where hosted delivery earns its keep. When a client says, "Maya finished the course but our LMS still shows incomplete," your team can inspect the hosted attempt instead of guessing.

It also produces better product feedback. You can see where learners stall, which assessment is causing trouble, and whether a new course version improved outcomes across customers.

Of course, retaining useful data also creates responsibility. Decide what learner information is necessary, document it in the customer agreement, keep it tenant-scoped, and do not collect fields simply because they are available.

Access Controls Are Part of the Product

Dispatch without access controls is just a remote link with better packaging.

A practical system should let the provider manage the commercial boundary around each export.

Maximum seats

A seat limit gives the license a measurable boundary. The provider should be able to see usage against the limit, and the behavior at the limit should be predictable. Do not wait until learner 501 arrives to decide what a 500-seat agreement means.

Expiration

An expiration date lets access follow the contract. It should also be possible to extend the date without forcing the customer to rebuild its entire LMS setup every time a license renews.

Allowed LMS origins

Origin restrictions help ensure the hosted launch is coming from the customer systems you expect. A copied launcher should not become a reusable key that works from any website on the internet.

A visible management record

Administrators need to see these settings after the export is created. If seat limits and expiration dates disappear into a one-time download dialog, someone will eventually manage the contract from a spreadsheet—and the LMS will stop being the source of truth.

The provider should be able to answer a simple question without opening a support ticket: "Who has access to this course, under what terms, and until when?"

Dispatch Should Not Be Limited to SCORM Content

This sounds contradictory at first. If the delivery package is SCORM, doesn't the course itself have to be one big SCORM file?

No.

The client LMS is receiving one aggregate course result. What happens inside the hosted course is the provider's responsibility.

That means a dispatched course can combine:

• an existing SCORM 1.2 or SCORM 2004 module
• a native video
• a text lesson or policy update
• a PDF or downloadable reference
• a native quiz with clean question-level reporting
• another required activity added by the provider

This is especially useful in compliance training. A real program might ask a learner to watch a current procedure video, complete an authored SCORM module, pass a short knowledge check, and review a policy document. The client should not have to import and assemble four separate objects.

The provider can sequence those activities as one course and send one final result back.

There is a second benefit: native content does not have to pretend it is SCORM. A video can use video completion rules. A quiz can store real question and answer records. A text lesson can use its own completion contract. The hosted course rolls those results up without forcing every activity into a 20-year-old data model.

SCORM 1.2 or SCORM 2004 for the Dispatch Package

For many clients, SCORM 1.2 is still the safest default because support is nearly universal. It provides the core fields most client LMS platforms need for a dispatched course: status, score, session time, and bookmark data.

SCORM 2004 separates completion from success and has a more capable runtime model. That can make the final transcript clearer, particularly when "completed but failed" is a meaningful outcome.

The receiving LMS should drive the choice. A client that has a well-tested SCORM 1.2 implementation may be better served by a 1.2 dispatch package even when the hosted course contains SCORM 2004 activities internally.

That works because these are two different layers. Edaxu can run the internal course and its sequencing, then translate the overall result into the version expected by the client LMS.

If you want the broader comparison, read SCORM 1.2 vs SCORM 2004.

A Few Implementation Traps Worth Knowing About

You do not need to build a dispatch engine to evaluate one, but knowing the common failure modes will help during a proof of concept.

Do not forward every child activity directly

If an internally hosted SCORM module sends its raw runtime calls straight to the client LMS, multiple activities can overwrite the same external course record. Internal navigation and the external transcript quickly drift apart.

The hosted platform should keep child activity state internally and forward only the course-level rollup.

Do not rely on the client LMS for internal sequencing

The client imported one launcher, not the provider's complete activity tree. It cannot correctly sequence activities it does not know exist.

Do not put the whole hosted state in suspend_data

SCORM storage limits are small, particularly in SCORM 1.2, and real LMS platforms do not always handle the limits gracefully. Keep detailed state server-side and use the external bookmark only for the small amount of coordination the launch actually needs.

Do not test only the happy path

Test a new learner, resume, completion, failure, retake, expiration, seat exhaustion, a copied launch from the wrong origin, and a client LMS that closes the player abruptly. Dispatch crosses browser, LMS, and network boundaries. The awkward exits are where most problems hide.

What to Ask During an LMS Demo

If you plan to sell or distribute training through customer LMS platforms, ask the vendor to show the whole workflow—not a slide that says "SCORM supported."

• Can I create both SCORM 1.2 and SCORM 2004 dispatch packages?
• Does the exported package contain my source content or only a hosted launcher?
• What completion, success, score, time, and resume data reach the client LMS?
• What detailed activity data remains visible to my administrators?
• Can a hosted course mix SCORM with native video, text, documents, and quizzes?
• Can I set and later change the seat limit and expiration date?
• Can I restrict launches to approved LMS origins?
• What does a learner see when access has expired or the course is already complete?
• Can support staff inspect failed launch and runtime calls without exposing raw internal state?
• How are course versions handled after a client has imported the launcher?
• Has the vendor tested the package in more than its own LMS?

The last question is especially important. A dispatch package exists to run somewhere else. Test it in the LMS platforms your customers actually use.

How Edaxu SCORM Dispatch Handles It

Edaxu SCORM Dispatch creates lightweight SCORM 1.2 or SCORM 2004 packages from published courses. The client imports one package and gets the aggregate course result. Edaxu hosts the course, runs its internal activity sequencing, and keeps the detailed session and diagnostic record.

A hosted course can combine SCORM packages with native resources such as video, text, documents, and quizzes. Each export can have a maximum seat count, expiration date, and permitted LMS origins, and administrators can return to the External Sharing view to see and update those controls.

That is the model we think makes sense for training providers: make the customer's LMS experience easy, but do not give up the information and controls required to run the course responsibly.

Frequently Asked Questions

Is SCORM dispatch part of the official SCORM standard?

SCORM dispatch is an industry term for a hosted delivery approach, not a separate SCORM specification. The exported launcher uses the normal SCORM 1.2 or SCORM 2004 runtime supported by the receiving LMS.

Does a dispatched course require an internet connection?

Yes. The small package in the client LMS launches content hosted by the provider, so the learner needs network access to the hosted course.

Can the client LMS still track completion and score?

Yes. A proper dispatch implementation sends the overall completion, success, score, and resume behavior back through the client LMS's SCORM API.

Can a dispatched course contain video, text, or a native quiz?

Yes, if the hosting LMS supports mixed-content courses. The external package reports one course-level result while the hosting platform tracks each internal activity using the data model appropriate for that content type.

Can I stop a client from launching the course later?

The hosting system should provide access controls such as expiration, seat limits, and allowed LMS origins. Confirm exactly how those controls work before choosing a dispatch platform.

Does the client need learner accounts in the provider LMS?

The learner launches from the client LMS, which passes the learner context required for the hosted attempt. The provider may maintain an internal learner or registration record for tracking, but the learner should not need a separate sign-in during a normal dispatch launch.

Should I use SCORM 1.2 or SCORM 2004 for dispatch?

Use the version the client LMS supports most reliably. SCORM 1.2 offers the broadest compatibility, while SCORM 2004 provides separate completion and success values and a richer runtime model.