Forum Discussion
Storyline 360 Quiz lockout after failed attempts(7-days cooldown)
Hi community,
I'm facing a significant challenge with my Articulate Storyline 360 project settings, and I'm hoping someone may have found a working solution for a similar scenario. I've already spent several days troubleshooting this issue, including working with Claude Pro, but I haven't been able to fully resolve it.
I have the following requirements from stakeholders for a 30-question quiz in Storyline 360:
1. The quiz should allow 2 attempts. The next 2 attempts qill be allowed aftr 7 days if the previous 2 were failed.
2. The passing score must be 100%.
3. If the learner fails the second attempt, the quiz should be locked for 7 days. Even if the learner closes and reopens the SCORM, it should still display that the quiz is locked and indicate when it will become available again.
4. Each time the learner opens the SCORM package, it should display how many days remain until the quiz is unlocked.
5. After the 7-day lock period expires, the learner should receive 2 additional attempts.
6. If those additional 2 attempts are also unsuccessful, the quiz should be locked permanently.
I have attached the story file with 3 testing questions.
I have managed to configure variables that lock the quiz after the second failed attempt. However, when I reopen the course, Storyline does not display the correct layer, and the learner is still able to click "Retry Quiz."
Our LMS does not provide functionality to support these requirements at the platform level, so the entire solution needs to be handled within Storyline and SCORM persistence.
I would greatly appreciate any advice, examples, or recommendations from anyone who has successfully implemented a similar solution.
It is very complex JavaScript engine to create and SCORM state-management challenge to fulfill your requirement. The main issue to consider is user manipulation. If you used a simple Date.now() countdown without properly storing the original unlock timestamp, a learner could potentially manipulate the browser / computer clock, refresh the course, or close and reopen the SCORM package and cause the timer to behave incorrectly. You need a reliable way to remember the exact moment when the quiz should become available again.
I would add the lock timestamp directly into SCORM suspend_data. But Storyline may continuously manage and update its own suspend_data and could later overwrite it, causing a timestamp to disappear.
The solution is to store the unlock timestamp in a dedicated Storyline variable, (eg. quizUnlockTimestamp), as a text value. The timestamp represents the exact future date and time when the quiz becomes available. Storyline then includes that variable in its own normal resume and suspend process. When the learner returns to the course, the script reads the stored timestamp, compares it with the current time, and calculates how much time is actually left. This means the countdown does not simply restart when the learner reopens the course; it continues based on the original unlock time.
The script also dynamically updates remainingTime so you can display the remaining time directly on the locked layer, while quizUnlocked changes to true only when the actual lock period has expired. The lock duration can easily be changed from minutes to hours or days without changing the rest of the logic.
Finally, the script includes SCORM API detection and should successfully detect the available SCORM version, so it should work with both SCORM 1.2 and SCORM 2004.
I built a simple Storyline file to test this logic and uploaded it to SCORM Cloud, and it seems to be working as expected. You may try the SCORM Cloud test link and see it for yourself. Let me know how it works for you and if you experience any issues. The current cooldown period is set to 1 minute purely for testing purposes. You may use a fake email address if you prefer when registering.The expected behaviour is as follows: Fail the quiz two times. Click the Retry button, and the Cooldown layer will appear. Close the course and reopen it (multiple times); the Cooldown layer should still be displayed, with the remaining time continuing to calculate correctly. Once the cooldown period expires, the Cooldown layer will automatically close, revealing the Failure layer underneath.
Clicking the Retry button again will provide two additional attempts. If the learner fails those two attempts as well, for a total of four failed attempts, the No More Attempts layer will be displayed.
7 Replies
This is a really interesting use case. The biggest challenge seems to be persisting the lock state and countdown across sessions rather than the quiz logic itself. I'm curious whether anyone has successfully implemented a time-based lockout entirely within Storyline using SCORM suspend data. Handling the 7-day cooldown, restoring the correct layer on launch, and enforcing a permanent lock after additional failed attempts sounds like a good test of Storyline's persistence capabilities.
It is very complex JavaScript engine to create and SCORM state-management challenge to fulfill your requirement. The main issue to consider is user manipulation. If you used a simple Date.now() countdown without properly storing the original unlock timestamp, a learner could potentially manipulate the browser / computer clock, refresh the course, or close and reopen the SCORM package and cause the timer to behave incorrectly. You need a reliable way to remember the exact moment when the quiz should become available again.
I would add the lock timestamp directly into SCORM suspend_data. But Storyline may continuously manage and update its own suspend_data and could later overwrite it, causing a timestamp to disappear.
The solution is to store the unlock timestamp in a dedicated Storyline variable, (eg. quizUnlockTimestamp), as a text value. The timestamp represents the exact future date and time when the quiz becomes available. Storyline then includes that variable in its own normal resume and suspend process. When the learner returns to the course, the script reads the stored timestamp, compares it with the current time, and calculates how much time is actually left. This means the countdown does not simply restart when the learner reopens the course; it continues based on the original unlock time.
The script also dynamically updates remainingTime so you can display the remaining time directly on the locked layer, while quizUnlocked changes to true only when the actual lock period has expired. The lock duration can easily be changed from minutes to hours or days without changing the rest of the logic.
Finally, the script includes SCORM API detection and should successfully detect the available SCORM version, so it should work with both SCORM 1.2 and SCORM 2004.
I built a simple Storyline file to test this logic and uploaded it to SCORM Cloud, and it seems to be working as expected. You may try the SCORM Cloud test link and see it for yourself. Let me know how it works for you and if you experience any issues. The current cooldown period is set to 1 minute purely for testing purposes. You may use a fake email address if you prefer when registering.The expected behaviour is as follows: Fail the quiz two times. Click the Retry button, and the Cooldown layer will appear. Close the course and reopen it (multiple times); the Cooldown layer should still be displayed, with the remaining time continuing to calculate correctly. Once the cooldown period expires, the Cooldown layer will automatically close, revealing the Failure layer underneath.
Clicking the Retry button again will provide two additional attempts. If the learner fails those two attempts as well, for a total of four failed attempts, the No More Attempts layer will be displayed.
Hi Nedim,
Thank you so much for your creativity and engagement. It works and meet all requirements. Wow! I appreciate the time that you spend on bulding that. If there is a way to receive a story file with the code and all settings inside the file? I would appreciate your support and openness to share the solution with us.
Hi Alena,
Please reach out to me at [email protected], and I'll be happy to send you the example .story file along with a few notes explaining how it works, especially the part where you'll need to specify your own time threshold (e.g., the number of days) to suit your requirements.
The reason I haven't uploaded it here is that it's a highly customized solution. I'd prefer to encourage discussion, feedback, and suggestions for improvements rather than have people simply download the file and move on without contributing to the conversation.
Once I hear from you, I'll send everything your way as promised.
Hi community, I have tested the solution and recreated it in my story project- all works perfectly. Thank you Nedim for your help and saving my time!
AlenaEgorova-5d : You marked your thanks as the solution to your question:
I'm guessing you thought that the "MARK AS SOLUTION" button only indicates that the overall issue has been solved. That's a fairly common mistake.
However, the "MARK AS SOLUTION" button applies to the specific reply where it is clicked.
When a reply is "MARKED AS SOLUTION," a copy appears directly under the question. (It also still appears in the entire thread of replies.) This helps others quickly find the answer when they have a similar problem.
In addition, the site tracks how many solutions each person has given. Nedim puts a lot of work into helping folks in the community. He deserves the recognition for solving the problem. So I suggest you unmark your reply, and then mark his reply as the solution.
