Part of my Oracle Fusion HCM Fix of the Day series: real issues from implementations and a Redwood rollout I led without a Systems Integrator, and how I fixed each one.
This is Fix #5. Start from Fix #1 to follow the series in order.
Learning was one of the phases in our Redwood rollout. Most of it went smoothly. Then learners started reporting that some SCORM courses would not launch in the new Redwood Learning pages. The course was there. The enrollment was there. The content just would not play. This post walks through the checks I use when SCORM content fails in Redwood.
The symptom
A learner opens the course and clicks to start the e-learning. Instead of the content, they get a blank frame, a window that never loads, or a player that opens and then stops. Other courses on the same page may work fine. That pattern matters. It tells you the problem is usually tied to the content or the way it is launched, not to the learner's enrollment.
Why it happens
A SCORM course is a package. It has a manifest that tells the player where to start and how to talk to the learning system. Fusion Learning hosts the package and launches it through its content player. The content then sends progress and status back to Fusion.
That chain has several weak points. The package can be built in a way the player does not expect. The player settings on the activity can open the content in a way the browser blocks. And the browser itself can stop the content from loading, for example through pop-up blocking or rules about content coming from a different domain.
Redwood changes the page around the player. Content that behaved under the older pages can react differently when the launch flow changes. So after a Redwood move, it is worth checking each link in the chain again, not assuming the content is still fine because it worked before.
How I fixed it
- I confirmed the scope first. Was it one course, one content vendor, or all SCORM content? Was it every learner or only some? This narrowed things down quickly.
- I tried the same course in a different browser and in a private window. This rules out cached files and browser extensions.
- I checked whether the browser was blocking a pop-up or new window when the content launched. Allowing pop-ups for the Fusion site is a common fix.
- I looked at the browser developer console while launching the course. Errors about blocked frames or cross-domain access point straight to a launch or hosting problem.
- I reviewed the package itself: the manifest at the root of the zip, the SCORM version it was built for, and the launch file it points to. A package zipped one folder too deep is a classic cause.
- I reviewed the player and launch settings on the learning activity, such as whether it opens in a new window or in the page.
- Where the package was the problem, I had it republished from the authoring tool, uploaded it again, and retested with a test learner before releasing it.
How to avoid it next time
- Test a sample of SCORM courses from each content vendor as part of Redwood testing, not just the page layout.
- Keep a short packaging standard for authors: manifest at the root, agreed SCORM version, tested export settings.
- Agree browser settings with your IT team, including pop-ups for the Fusion domain, before go-live.
- Always check completion tracking too. A course that launches but never reports status is the next ticket waiting to happen.
- Keep a test learner account in each environment for quick launch checks after quarterly patches.
Key takeaway
When SCORM content fails in Redwood, work through the chain in order: browser, launch settings, then the package. Most failures sit in one of those three places.
Next in the series: Absence approvals sending FYI notifications to the wrong people, and how OR versus AND in an approval rule changes who gets notified.
Meeramaheswari Annadurai, Oracle HCM & Enterprise AI. More at meera2k10.github.io/enterprise-ai
```
