Sharing Storyline files: the 2026 way.

A buyer asks for "a couple of samples," and you feel your stomach drop. Version 1.2 is still in Articulate Review. Version 1.3 went to the client's LMS team as a zip. Your actual best work is trapped in a closed pilot behind someone else's SSO. So you forward three old email threads and pray nothing 404s before they click. The work is strong. You look disorganized anyway.

That gap — great Storyline build, shambolic delivery — is almost always a sharing problem, not a design problem. Zip attachments are dead. Articulate Review is a paid seat that reviewers confuse with your portfolio. In 2026 the move is one stable, clickable link that runs the real module — plus the SCORM API quirks nobody warns you about until completion silently fails.

Stop forwarding three threads. Send one link that runs the actual course.— the whole post in one line

The zip-and-Review trap.

Link sprawl is the quiet killer. Review links expire, they live in scattered inboxes, and they only ever show one module — never your range. Every extra stakeholder multiplies it: sales joins late and asks for "the portfolio," legal wants "the approved demo," and procurement wants "samples." If your answer to each is a different forwarded thread, you read like a freelancer juggling files instead of a partner.

It gets worse across time zones. APAC tests a build while the US is asleep; by morning nobody agrees which URL is "current." Every link you send is another failure point — someone forwards the wrong build, someone loses access after a team change, someone opens it on a browser combo your package never saw.

And Articulate Review actively trains the wrong instinct. Reviewers remember the comment rail, not your design rationale. Review chrome makes everyone think in slide-level fixes — swap this image, shorten this audio — which is exactly right during a build and exactly wrong when a buyer is deciding whether to trust you with a six-month curriculum.

One link, not a scavenger hunt.

The fix is boring and it works: a single portfolio URL that stays constant, with hosted SCORM living inside it. Think of it as packaging. The SCORM package is the executable. The case study is the README. Your profile page is the installer that ties them together. Without that bundle, clients only ever experience fragments.

Treat the page like a product page, not a dump of every export you ever made. Curate the projects. Lead with the problem each one solved, not the tool list — tools belong in tags beneath the headline. If a client needs several modules, group them under one case study with clear "Module A / Module B" labels so the narrative stays coherent. You can host the package on something purpose-built in a couple of minutes and skip the LMS and AWS setup entirely.

Then enforce one rule on your side: Review links rotate with builds; the portfolio link is constant and always points at the approved-demo set.Put the canonical URL in your email signature so clients learn where to return. When you refresh a module, reuse the link and say "same link; refreshed Project X on [date]." That one habit prevents the "which build did Legal approve?" archaeology later.

Public work and NDA work are different URLs.

If you have both marketing samples and confidential proofs, split them on purpose: a public page with anonymized work, and a gated or signed-link path for the NDA build. Write that policy into your proposal so nobody expects the secret module to live at your homepage. Match the client's screenshot rules in your file naming too — some allow fake data but forbid industry names — so you never grab the wrong asset at 11pm under pressure.

How to actually send it, ranked.

Three ways people share Storyline work, ranked by how rarely they embarrass you.

The SCORM quirks that bite you.

Even with a working host, the package itself has sharp edges. These are the ones that turn a clean demo into a "the client thinks they broke it" ticket.

1. The 1.2 vs 2004 version mismatch.

Storyline lets you publish as SCORM 1.2 or 2004, and they use different API names — cmi.core.lesson_status for 1.2, cmi.completion_status for 2004. Publish as 2004 and play it through a 1.2-only path and the course runs, but completion never fires. Check the publish dialog before you blame the host.

2. The suspend_data ceiling.

SCORM 1.2 caps cmi.suspend_dataat 4,096 characters; 2004 raised it to 64,000. Storyline crams a lot of branching state into that field, so a long scenario course can quietly blow the 1.2 limit and break "resume where you left off." For anything with real branching, publish SCORM 2004 4th Edition.

3. Test the launch logged out before you send it.

Your admin session bypasses caches and access rules, so the link looks perfect to you and dies for everyone else. Open the raw launch URL in an incognito tab — audio, completion, resume — before it ever reaches a client or a hiring manager. That is the only view that matches what they see.

// The course hunts for the API on the parent window.
// No API found in time = silent failure, zero data recorded.
var API = findAPI(window);

// Open the session. A good host returns "true".
API.LMSInitialize("");

// Write the state that buyers actually check.
API.LMSSetValue("cmi.core.lesson_status", "completed");
API.LMSSetValue("cmi.core.score.raw", "87");

// Commit, then close — or the writes never persist.
API.LMSCommit("");
API.LMSFinish("");

Narrating the work without the .story.

Decision points, variables, and scenarios never show up in a static PDF — which is exactly why hosted SCORM matters. Let reviewers click the real paths, then pair it with a short process write-up: objectives, constraints, what you tested in QA, and how you measured success. That turns "here's a module" into "here's how I think."

Use the Storyline vocabulary that signals seniority: variables that track branching, question banks with randomization, custom triggers that enforce attempt limits or lock navigation for a compliance rule, and how you handled resume behavior. An author-reviewer looks for those words; a non-technical buyer still understands "learners saw different paths based on role." Translate when needed — "12 triggers on slide 3" means nothing, but "the module remembers earlier choices so escalation paths match policy tiers" sells the behavior.

Add a plain-language QA appendix: devices tested (Chrome, Safari, Edge), the LMS used for the pilot even if anonymized, and known limits like "audio autoplay blocked on iOS until a user gesture." If you cannot host the exact module publicly, show a redacted variant — blur logos, swap names, replace proprietary data with obviously fake numbers and label it anonymized so nobody mistakes it for live metrics. The goal is evidence of interactivity, not a slide count.

Frequently asked questions.