Skip to main content

SCORM Widget

Updated

Table of contents

Overview

The SCORM Widget allows SCORM-based learning content to be surfaced through a WebLink-powered learner experience. It is used when you want a learner to access SCORM training from a web-based storefront or portal journey rather than only through a traditional internal LMS navigation path.

In practice, the SCORM Widget helps bridge the gap between course discovery and learning access. A learner can discover training through a WebLink-driven experience and then launch the associated SCORM content from the appropriate learner-facing page.

If you have not yet configured the broader WebLink environment, start with WebLink Overview and Installation. For general widget-building steps, see WebLink Widgets.

How the SCORM Widget works

The SCORM Widget displays learner-facing access to SCORM training that is already configured within Administrate. This means the widget does not create SCORM content on its own. Instead, it depends on the underlying course, learning content, and learner-access rules already being in place.

That makes the SCORM Widget different from a catalog or checkout widget:

  • the Catalog Widget helps a learner discover training
  • the Checkout Widget helps a learner complete registration or booking
  • the SCORM Widget helps a learner access SCORM-based learning content once the relevant access conditions have been met

Administrate’s embedded content players can be used to surface SCORM and video content directly on your own website, including for anonymous users or users who already exist as Contacts in Administrate.

Typical use case

A common use case looks like this:

  1. A learner browses training through a WebLink-driven experience.
  2. The learner registers for or is assigned training that includes SCORM content.
  3. The learner reaches the relevant learner-facing page.
  4. The SCORM Widget displays the launch or access point for the learning content.

This is most effective when the wider learner journey has already been designed clearly, so the learner understands when they are browsing training, when they are registering, and when they are launching learning.

Before you build the widget

Before generating the SCORM Widget, confirm:

  • the relevant course or learning product is configured correctly in Administrate
  • the SCORM content is already associated with the correct training item
  • the learner has the required access to the training
  • your WebLink environment is already working

If those prerequisites are not in place, the widget may load but still fail to present usable learning access.

Authentication and access

Embedded SCORM access relies on a signed JWT that identifies the user interacting with the content.

To support this, first generate a pair of Public and Private Keys:

  • store the Private Key securely on your server and use it to sign JWTs
  • provide the Public Key to Administrate so it can be registered in the platform

The private key should never be exposed directly to browsers or other clients.

When a user accesses your website, your application should generate and sign a JWT for that user before loading the embedded player.

JWT requirements

The signed JWT must use the ES256 algorithm.

It must include the following claims:

  • iat – issued-at time in Unix epoch format
  • exp – expiration time in Unix epoch format
  • sub – the subject identifier
  • sub_type – the type of subject being identified

If the JWT identifies an anonymous user

  • sub_type should be "tracking_id"
  • sub should be a unique tracking identifier for that anonymous user

If the JWT identifies an existing Contact

  • sub_type should be "contact"
  • sub should be the GraphQL ID of the Contact in Administrate

To reduce risk, use short-lived JWTs of no more than about one hour.

Generating the SCORM Widget

The easiest way to generate the widget is by using the WebLink Builder.

  1. Open the WebLink Builder.
  2. Enter your portal address URL.
  3. Select the timezone if required by the builder flow.
  4. Choose SCORM Widget from the widget list.
  5. Adjust the available configuration options.
  6. Click Build to generate the code.

The builder will generate:

  • the shared WebLink script required for the page
  • the widget container used to render the SCORM experience

Both parts must be present on the page.

Example widget container

A basic SCORM Widget container may look similar to this:

<div class="administrate-widget" data-widget="scorm"></div>

The exact generated code will vary depending on the builder configuration and the specific experience you are implementing.

Embedded SCORM Player implementation

Once you have generated a signed JWT, you can render the embedded SCORM player on your page.

Example implementation:

<section id="administrate-scorm-player"></section>

<script
  type="module"
  src="https://lms-ux-assets.getadministrate.com/ux/embedded-scorm-player-latest/embedded-scorm-player.js">
</script>
<script type="text/javascript">
async function getJwt() {
  // Fetch signed JWT here
  return "YOUR_SIGNED_JWT";
}

function handleLoad() {
  console.info("The SCORM Iframe has loaded");
}

function handlePass() {
  console.info("The learner has been marked as passed by the LMS API");
}

function handleFinish() {
  console.info("The learner has finished the SCORM");
}

function handleError(error) {
  console.error(error.message);
}

window.addEventListener("DOMContentLoaded", () => {
  window.AdministrateScormPlayer.render({
    rootId: "administrate-scorm-player",
    rootElement: document.getElementById("administrate-scorm-player"),
    getJwt,
    portalUrl: "https://yourinstance-portal.administratelms.com",
    brandId: "GRAPHQL_BRAND_ID",
    contentId: "GRAPHQL_CONTENT_ID",
    eventId: "GRAPHQL_EVENT_ID",
    learningPathId: "GRAPHQL_LEARNING_PATH_ID",
    onScormFrameLoad: handleLoad,
    onPass: handlePass,
    onFinish: handleFinish,
    onError: handleError,
  });
});
</script>

If both learningPathId and eventId are provided, the learning path context takes priority.

Where the SCORM Widget fits in the learner journey

The SCORM Widget should usually appear only after the learner has reached the correct point in the journey.

For example, it may make sense to use:

  • a catalog page for discovery
  • a checkout or booking step for registration
  • a learner-facing page with the SCORM Widget for launch or access

This separation keeps the storefront understandable and prevents learners from encountering learning-launch components before they have the right context or permissions.

Testing the SCORM Widget

Before publishing the page, test the widget using a real learner scenario.

  1. Open the page containing the SCORM Widget.
  2. Confirm the widget loads correctly.
  3. Confirm the learner can see the expected training item.
  4. Launch the SCORM content.
  5. Verify the learner reaches the correct learning experience.
  6. Confirm the result matches the expected learner-access rules.

This matters because issues with SCORM access are often caused by the underlying learning setup rather than the widget itself.

Common issues

The widget loads but no learning appears

  • Confirm the learner has access to the relevant training.
  • Confirm the training item is linked to the expected SCORM content.
  • Confirm the learner is viewing the correct page and context.

The learner cannot launch the content

  • Confirm the SCORM setup is complete in Administrate.
  • Confirm the learner has the right registration or assignment.
  • Confirm the page includes the correct shared script and widget container.

Getting a CORS Policy error

A visible CORS error is often a symptom of a deeper underlying issue.

  • Check whether isPublic has been set correctly on the content
  • Confirm the content is actually a SCORM package, not just a single HTML file stored in the DMS

In some cases, asset types such as fonts may be blocked by CORS policy and require infrastructure-side adjustment.

Getting a CSP Policy error

This usually means the host application’s server needs an updated Content Security Policy to allow the required asset or API to load from the embedded iframe context.

The learning experience appears in the wrong place

  • Review where the SCORM Widget is placed in the overall learner journey.
  • Make sure the widget is being used on the intended learner-facing page.
  • Confirm the learner is not being sent directly to launch content before completing the expected discovery or registration steps.

Best practices

  • Use the SCORM Widget only after the broader WebLink environment is working correctly.
  • Test with a real learner account rather than only an admin view.
  • Treat the widget as one part of the learner journey, not as a standalone learning setup tool.
  • Keep the navigation clear so learners understand when they are browsing, registering, and launching training.
  • Keep your private signing key server-side only.
  • Use short-lived JWTs and regenerate them when needed.

Related articles