Setting Completion Based On Runtime Completion for Articulate Rise Courses
This is a feature that we developed for the Articulate Rise content production tool. In our testing, some publishing settings with Rise [where a quiz is included and completion is based on whether the quiz is passed] lead to registrations going incomplete or unknown, even if the quiz is passed and success is posted as passed.
We've built some compatibility logic into Bright to help work around this issue. Note, this may not work on other course production tools.
First find your course in the course metadata editor in Bright, and then add a custom field called:
By runtime, we specifically refer to the runtime schema made available in a SCORM Cloud registration. This data is collected by SCORM Cloud, and in some cases, we have observed the case where a learner reports they completed their quiz, and the completionStatus is set to 'complete' in the runtime schema, but the registration itself did not rollup correctly.
Setting SCORM Success Variable to Passed Whenever The Registration Is Complete
For occasions where you have rogue courses that don't update their passed status, but you WANT or NEED the course passed in Bright, you can set a custom course property in your Bright metadata:
The field name is completion_means_success.
With that set, every time a registration is updated for this course, if the registration is marked 'complete', it will be 'passed' as well.
Note, this may not fix existing registrations that were updated BEFORE the change. But no worry, our awesome support will fix that for you in a jiffy.
Under the covers, this is an after_crawl registration hook compiled into the Bright server. There are LOTS of things you can do with hooks....
Got custom work you need to do to your registrations every time they are changed [aka launched]? Ask us, we do that.
Using Launch Data
With some course production tools, learner progress can be wiped out when re-launching the course.
This can be very frustrating for both learners and administrators.
By setting a course metadata field called
to any value, Bright will propagate the following fields:
- best launch score
- any launch completed
- any launch passed
- best launch exited at
- completed at
Note, completed at is only overridden if any launch completed is true.
This can also be useful for courses that don't always roll-up their registration data reliably during course exit.
Important: this field will not overwrite successful data. That is, if the registration status return from SCORMCloud is not improved by the launch data, the registration data is preserved. You cannot have a passed or compete registration marked to incomplete or failed by launch data.
Setting a Registration Complete Based on Quantity of User Interactions
We've encountered issues in the field, specifically with SCORM Cloud Quizzage courses used as surveys, where in some cases the learner will have completed the survey, but the registration will not roll-up correctly.
We've also had cases where this setting has been required for Articulate Rise courses.
In almost all cases, the number of interactions will reach a set number, equivalent to the number of interactions in the survey.
In Bright, you can set a course metadata field called:
If this field is set to 7, for example, 8 interactions will cause the registration to be marked complete.
Note, only complete can be set with this field.
If the registration is already marked complete in the course provider [aka SCORM Cloud], the rule does not run.
Viewing Rules Applied
Bright fault-masking rules like these that are applied to a registration during its crawl phase are permanently recorded on a field called
You can view this data in the Registration Explorer in both the Inspect and Show functions.
Please Note . Currently, if you override registration data by clicking edit in the registration explorer, there is no "rule applied". You MUST click ignore during your edit session to ensure that the record won't be recrawled.
When does this run?
These rules are applied by the Bright Event Manager in the after crawl event. This means if you change or add a rule to a course, you can force these rules to apply by initiating a crawl from the registration explorer.