It is a bad morning. The course is in the LMS and running fine, somebody needs one policy line changed, and the .story file is not where it should be. The contractor who built it has moved on, or the person who had it left and their laptop went back to IT, or the shared drive was reorganized two years ago.
Before anybody rebuilds anything, work through the six places below. The file is found more often than people expect, and finding it beats every other option in this guide by a distance.
Six places the file may still be
1Review 360, if the course was ever sent for review
This is the one people miss. When a Storyline course is published to Review 360, the author can tick Upload project file to Review 360, which stores the .story file itself alongside the published version. Anyone with access can then download it.
Open the item in Review 360, click the Version drop-down at the top left, and look under each version for a Download project file link. It appears on versions that were published with that box ticked, so check older versions too: a course reviewed five times might have the project file on two of them. An older source file plus your published course is still a far better starting point than no source file.
One warning while you are in there. Restoring an old version in Review 360 permanently deletes the newer versions, their comments, and their project backups. If you only want to look at an older version, select it from the drop-down rather than restoring it. Articulate’s page on Review 360 versions spells this out.
2Storyline's own recovery copies, if it crashed
If the file went missing after a crash rather than after a cleanup, open Storyline 360 and try to open the project. Storyline keeps temporary versions and offers to restore them when you next open the file, with a drop-down for each one so you can pick the most recent timestamp.
If nothing is offered, look in the folder Storyline keeps those temporary copies in. Press Windows+R, paste %appdata%\Articulate\Storyline and press Enter. Sort by date, look for a file whose name starts with your project’s, copy it to your desktop, and rename the extension from .tmp to .story. Then open it. Work on a copy, never on the original.
3Version history and the recycle bin of wherever it lived
OneDrive, SharePoint, Dropbox and Google Drive all keep deleted files for weeks after somebody deletes them, and they all keep version history for files that still exist. On a work OneDrive or SharePoint site the recycle bin holds deleted files for 93 days, in two stages, and a site admin can see the second stage after you have looked through the first.
It is worth searching the whole drive for *.story rather than only looking where the file should be. Project files get dragged into personal folders far more often than anyone admits.
4The backup of the machine it was built on
If it was built on a company laptop, that laptop probably had a backup policy, and the file may exist in an image even though the laptop was wiped. This is a two-minute question to IT and they can answer it faster than you can rebuild a single slide. On a machine you still have, right-click the folder it lived in and look at Restore previous versions.
5The vendor, and what your contract says
Ask plainly, and ask for the .story file rather than the course. Many agencies keep project files for years and will hand one over for the asking, particularly if you are still a client.
Before the call, read the statement of work. If source files were named as a deliverable, you are asking for something you already own rather than asking a favor, and the conversation is short. If they were not named, this is the moment that changes how you write the next contract.
6Anywhere the file was ever sent
Search email for .story attachments and for the WeTransfer or Dropbox links people use when the file is too big to attach. Search Teams and Slack the same way. If your team used Storyline’s Team Slides library, whatever anyone shared to it is still there and can be pulled into a new project.
When it is really gone
A published course is not the project file, and nothing turns one back into the other. What a published course does contain is most of what you would spend the first week of a rebuild retyping, because the player needs it in order to run: the text of every slide, the asset library, the notes, the questions with their correct answers, and the captions, if the course was captioned.
That means a published SCORM, xAPI or Web package is worth opening before anyone starts typing. The Course Content Recovery tool reads one in your browser and gives you back the parts that can be read.
What that actually gets you
A real example, a 37 slide compliance course published for SCORM. From the package alone:
- 2,200 words of on-screen text, slide by slide, in a Word storyboard
- the narration script, recovered from the captions on all 50 audio tracks, next to the slide it belongs to
- the slide notes from 17 slides
- all 17 quiz questions with the correct answer marked, in a text file that Storyline imports through File > Import > Questions from File
- 136 media files renamed from things like
6hGC5LZ94Ii.jpgto01-12 Prevent Heat Stress - image 1.jpg - a 103 slide PowerPoint deck, each slide redrawn with its text boxes, pictures and panels where they were, which Storyline imports as slides
That is a rebuild that starts with the words written, the pictures named, the questions loaded and the layouts roughed in.
What does not come back, ever
Everything that makes it interactive. Triggers, states, variables, layers’ behavior, animations and timing are compiled into the published output as instructions for the player, and reading them back into an editable project is not a thing any tool does. Neither is the .story file itself.
Two more honest limits. Narration comes back as words only when the course carried closed captions; if it did not, you get the audio files and no script, because nothing here transcribes speech. And slide notes only come back when the Notes tab was switched on in the player, since that is the only time Storyline publishes them.
Rise courses are a different problem
A Rise course lives in the Articulate account rather than on somebody’s computer, so the first move is not a file hunt, it is asking whoever administers your Articulate 360 team to look for it, or to look in the account of the person who left. The recovery tool reads a published Rise package too, which matters when the account itself is gone: an agency that built the course in their own Rise account, or a team whose subscription lapsed.
How long the rebuild will take
Before you promise anyone a date, put the numbers into the Development Time & Cost Estimator. A rebuild from a storyboard and named media is not a fresh build, but it is not a small edit either, and the estimate is the difference between a schedule and a hope. The Course File Inspector will tell you what is in the package first: how many slides, how much narration, how much of it is captioned.
So it does not happen again
- Tick Upload project file to Review 360 every time you publish for review. It costs nothing and it is the single thing that would have saved most of the people reading this page.
- Keep .story files in a synced, versioned folder rather than on a desktop. Storyline cannot open a project over a network drive safely, so work locally and let the sync client copy it up.
- Name source files with a date, and keep the published zip next to the project file. As this page shows, the published zip is worth something on its own.
- Put source files in the contract as a named deliverable, with a format and a date. One line now, one fewer bad morning later.