Forum Discussion
Everything we know about Cornerstone on Demand and Storyline!
I thought I would start a thread about Cornerstone on Demand so there's a central place for people to read and add to. There seems to be a dearth of information about how CSOD and Storyline interac...
New problem: I decided to set up a bunch of Storyline courses in Cornerstone to have completion based on number of slides viewed. So for a course with 25 slides, I set it to 24 (giving the user a slide they can miss). However, I am getting numerous reports now that these courses are not completing for people even though they say they are viewing all the slides before exiting the course.
So now I want to modify these courses so they complete based on a one question quiz at the end and ditch the "number of slides" criteria (because 1. it doesn't seem reliable and 2. it is the learner's word vs the LMS since I can't really argue when they say they viewed all the slides)
The Question: Since I am changing the way a course is completed, can I just modify it without creating a new version of the course? Or is this a significant enough change that I need to create a new version.
Hi Will,
You'll have to create a new version. I've been told by Cornerstone support that just replacing the file will only work for a very minor change like fixing a spelling error. When I tried to do this before and just replaced the file, no one was getting the newer version if they already had it on their transcript. Creating a new version fixed that issue.
Sounds like you are adding a slide and changing what is reported to the LMS. As a rule, we deem that significant enough to warrant a new version.
Here's the rub. While the new version will go out to anyone who is registered for the course after it is reversioned, the new version does not go out to users who already have the course on their transcripts by default unless you push the new version out to them. Also, reversion does require you to go back into the catalog and reset your populations/availability, etc. In order for users who are already registered in the course to get your new version, you will need to redo the proxy enrollment using the "Force" enrollment option. Some users may lose progress, so you may wish to evaluate specifically how many in progress users do you have and to whom do you wish to push the new version.
Any time I can avoid a reversion, I do. We have successfully used slide count to log completions. The most common offender in the slide count is a lightbox or branching slide. That said if your course has a menu it should be pretty easy to determine if they missed a slide. We request a screen shot as proof for something like that.
Thank you for laying out the challenges involved with reversioning. We're about to launch CSOD and I'm sure this is something we're going to run into.
Thanks Matthew for the info about reversioning. It also seemed like when I reversioned that I had to back in and add the CSOD Evaluation to it again.
Also, when I created the course I had checkmarked the option to pre-register people into the course in the curriculum it was in (to save them the extra click.) I don't think I'll do that again, as it took a long time to figure out how to get people the new version. Fortunately I came across this gem in the help docs:
Reversioning a Course that Is Part of a Curriculum
...
If it is necessary for all impacted users to receive the new version of the course, then you can run a Transcript Status report in Standard Reports that provides all users that currently have the course in an In Progress or Completed status. You can then proxy enroll those users into the new version of the course.
...
If I am remembering correctly, I ran the report for those people in Registered or In Progress Status (since I didn't want to bother those who Completed it), created a CSV file with their IDs, and then Proxy Enrolled them into the course again which bumped them up to the new version.
You are correct in all of that Will. When you reversion, you have to go back through and reset all of your catalog settings (i.e. the new version does not inherit the old version's settings). After that we ran that same report and had to proxy enroll those "In Progress" and "Registered" as you said. For "In Progress" progress is lost.
How you go about that last part really comes down to why the reversion was done. If the new version doesn't need to go to existing users, all the messing around with proxy enrollments, etc is unnecessary. Any users registered after the new version is activated will receive the new version, (provided the availability was properly set in the catalog).
However, if the reversion was to correct a major defect or content error, and everyone needs that version then running through the proxy enrollment process becomes necessary.
All of that rigmarole, is why if I can just do a file update instead of a full on reversion, I do. File update pushes out to all users of your existing version immediately. The hazard being file update can totally corrupt a course, if the changes are more than a minor adjustment to course content.
