Brightspace Course Export Contents

Question

I have a lecturer who has tried exporting a lesson in one course to then reimport as a SCORM into another course on Brightspace. We've been having challenges with ensuring the content is exported and re-imported accurately. We did notice that H5P links in the SCORM always break while exporting and don't display correctly when we try and open the SCORM in the destination course. Is this because H5P activities need to be refreshed/ re-added to the SCORM in the destination course as the links expire?

The Lecturer has also mentioned that upon examining the contents in the exported SCORM zip, a manifest file is missing. What can we do about this?

Brielle.H.672 · Accepted Answer

Hello! I ran these questions through our internal knowledge bot and this is what I came up with. Please have a read through and let me know if it helps with your questions….

You’re running into two separate, but related, issues here:

* H5P content breaking when moved as part of a SCORM export/import
* A missing imsmanifest.xml (SCORM manifest) in the exported zip

I’ll walk through each and what you can realistically do in Brightspace.

1. Why H5P links break in the exported/imported SCORM

What’s likely happening

In most Brightspace workflows:

* H5P content in a course is not actually “inside” the SCORM package.
* Instead, the lesson content (HTML, pages, etc.) contains links or embed codes that point to H5P objects stored in the originating course (or in your institution’s H5P repository / LOR).
* When you export the lesson as SCORM and import it into a different course:* The SCORM package still has links pointing back to the original course’s H5P IDs/URLs.
* Those links may:* Be inaccessible due to course-level permissions, or
* Reference IDs that don’t exist in the destination course, or
* Use absolute URLs that are no longer valid in that context.

So the H5P links “break” not because they “expire” in time, but because the references are course-specific or environment-specific and don’t remap on import.

Do H5P links “expire”?

Typically:

* H5P activities themselves don’t have a natural time-based expiry.
* What can “expire” are:* Authenticated session tokens (so an unauthenticated user can’t see embedded content).
* Course enrollments / permissions (so users in the new course don’t have rights to see the original course’s H5P).
* Temporary or environment-specific URLs if the export tool rewrites them in a brittle way.

So the key problem is context mismatch, not time expiry.

Do H5P activities need to be refreshed/re-added?

In practice, yes:

* If the SCORM you exported was just wrapping links back to H5P in the source course, then in the destination course you will typically need to:* Recreate or copy the H5P activities into the destination course (or into a central H5P repository that both courses use).
* Update the SCORM content (or, more realistically, the lesson content in the new course) to embed/link the new H5P objects.

Depending on how you’re using SCORM:

* If your goal is true, standalone SCORM that contains H5P content inside the package:* The H5P content has to be authored/exported as part of that SCORM package by the H5P tool itself (e.g., using H5P’s own export-as-SCORM capability, where supported).
* Brightspace course exports that include SCORM components generally do not repackage third-party interactive content into the SCORM zip automatically.

So yes: in most Brightspace use cases today, you will need to re-link or re-add H5P activities in the destination course rather than expecting them to survive as part of a generic SCORM export/import.

2. Missing SCORM manifest file (imsmanifest.xml)

What the manifest is

A valid SCORM package must contain:

* An imsmanifest.xml file at the root of the zip.
* This file declares:* The SCOs (Sharable Content Objects),
* Launch files,
* Organization/structure,
* Metadata, etc.

SCORM players—including Brightspace’s SCORM engine—use that manifest to know what to launch and how to track progress.

Why your exported zip might not have it

Common reasons in this scenario:

* What you exported is not actually a SCORM package* If the lecturer exported:* A “course package” or “content export”,
* An individual “module/lesson”,

* Those exports are often in Brightspace’s own course package format, not SCORM.
* That format does not need imsmanifest.xml; instead it uses Brightspace-specific XML files and folder structures.

* The original content was never a SCORM object to begin with* If the original “lesson” was a Brightspace Content module with H5P inserts, it’s not SCORM-native content.
* Exporting that module won’t magically generate a SCORM-compliant manifest; it will just export in Brightspace’s course format.

* You’re inspecting the wrong level in the zip* Rarely, a system will nest SCORM packages inside a larger export.
* Always check the root of the zip: if there is no imsmanifest.xml at root, the zip is not a SCORM package by SCORM’s definition.

What you can do about the missing manifest

There are really only two reliable options:

Option A: Export a true SCORM package from the original tool

If your requirement is “I need SCORM that can be imported anywhere and behave as SCORM”:

* Identify where the content is authored:* If the lesson is built in H5P itself:* Use H5P’s Export as SCORM feature (if your institution has that enabled / supported).
* That export should yield a zip with an imsmanifest.xml at the root.

* If the lesson is built in another authoring tool (Articulate, Captivate, etc.):* Export directly from that tool as SCORM 1.2 or SCORM 2004.

* Import that SCORM zip into the destination Brightspace course using the SCORM-specific import flow.

This ensures the manifest is properly generated and included.

Option B: Accept that this is a Brightspace course export, not SCORM, and copy via Brightspace-native tools

If the goal is just to reuse the lesson between Brightspace courses, and you don’t truly need it to be SCORM at all:

* Use Brightspace’s course copy / copy components features to:* Copy the module/lesson,
* And copy the related H5P activities (or learning objects, depending on how H5P is integrated at your institution).

* This route:* Avoids SCORM entirely,
* Preserves H5P linkages better (because Brightspace understands its own IDs and can sometimes remap them on copy).

Trying to “add” a manifest manually to your current exported zip will almost never be worth the effort—SCORM manifests are heavily structured and must match all internal file paths and IDs.

Francisco.V.2799 · Accepted Answer

Hello, The explanation shared above is a good overview of what is likely happening. I just wanted to add a bit of clarification from the Brightspace platform perspective. 1. H5P content inside exported lessons In Brightspace, H5P activities are typically stored as separate learning objects (either in the course itself or in the H5P repository/LOR depending on the institutional setup). When lesson pages containing H5P embeds are exported as part of a package, those pages often retain references to the original H5P object IDs or URLs. Because of this, when the package is imported into another course: * The references may still point to the source course context, or * The destination course may not contain the corresponding H5P object. When that occurs, the embedded H5P activities will appear broken. In most cases the activities need to be copied or recreated in the destination course and re-embedded in the content. 2. Missing imsmanifest.xml If the exported ZIP does not contain an imsmanifest.xml file at the root, then it is not a SCORM package. Brightspace course exports (for example when exporting course content or modules) often produce a Brightspace course package, which uses a different internal structure rather than a SCORM manifest. Because of that, importing the file as a SCORM object will not behave as expected. Recommended workflow If the goal is simply to reuse the lesson between Brightspace courses, the most reliable approach is usually to use: Course Admin → Import/Export/Copy Components → Copy Components from another Org Unit This allows Brightspace to maintain internal references and usually avoids issues with embedded objects or linked activities. If SCORM is specifically required, the package generally needs to be exported as SCORM directly from the original authoring tool that created the learning object.