Working locally is essential. I don't think it's an application flaw with Storyline so much as it is a conflict with backup/active malware detection. IT security/backup/update processed often interfere with tools like Storyline, and IT rarely understands how Storyline works, unless they work with software developers.
Remember that course developers are actually software developers. We may not be code warriors, but we are producing executables that send data from a local system, which resembles malware to aggressive/clunky security software. Storyline is going to react differently than tools like InDesign or most Microsoft products. Those don’t generate executables; Storyline does.
Backup software can interrupt normal authoring tool functionality, in particular when you are publishing and you have a large or complex project. It was such an issue at one gig I had that we ended up getting approval to store our working files at the root level, outside of the normal user document path (not Storyline, but similar application). Once our working folders weren’t getting probed every five minutes by “helpful backups,” we stopped experiencing the lost work and file corruption.
I’ve acted as first line of support for instructional developer teams I’ve worked on for years (I came from a tech support background). By far the most common issues have been caused by working from a networked copy, and lax saving habits. The next most common issues are a tie between missing administrative privileges for Storyline (and related tools), and working with ancient and complicated course files that had been imported without being cleaned up.
It would be useful to have better documentation for how security/backup software can impact Storyline, if only to say, we instructional developers are in fact special, unlike 95% of the computer users in an organization.