We’ve created a course that is peppered with required knowledge checks authored in Rise 360. When users complete the course, they are unable to review the content of the course without resetting the course (which is expected). So, we’re thinking the required knowledge check content prevents users from viewing content unless they retake the checks? If anyone has similar experiences, please verify this behavior and if there’s a workaround, please share. Thanks!
Best Answer
Articulate 360 Required Knowledge Checks and Free Navigation
Best answer by Moshe.Machlav
Thanks for the clarification, Thammo. If the navigation is already set to Free and the Continue blocks are configured correctly, this behavior points to a data communication constraint.
In organizations I've worked with, when Rise course progress behaves erratically upon return, saving some block completions but "reopening" or resetting others—we typically look at two main culprits: session timeouts and SCORM data limits.
1. Session Timeouts (Very common with knowledge checks): If a learner leaves a knowledge check open and idles for an extended period, their background Docebo session may time out. When they finally click forward, the SCORM package attempts to send an LMSCommit (save) action to a connection that is no longer active, resulting in lost progress for that specific block.
2. The SCORM 1.2 Data Limit: Rise tracks progress at a highly granular level, recording data for nearly every block. SCORM 1.2 strictly limits bookmarking data (suspend_data) to 4,096 characters. Content-heavy courses easily exceed this limit, causing the LMS to stop recording new progress data reliably. If you're using SCORM 1.2, republishing as SCORM 2004 (3rd or 4th Edition) or xAPI often resolves this completely.
To see exactly what bookmarking data Docebo is actively receiving and where the communication drops off, you can review the specific SCORM CMI tracking logs by checking the User Statistics tab within the Course Report.
+1Hi
This is expected behavior, but the limitation actually comes from how Articulate Rise authors its SCORM data, rather than Docebo itself.
When you set a Rise course to "Restricted" navigation, Rise bakes that restriction into the SCORM package's tracking data (cmi.suspend_data). When a user completes the course and later re-opens it in Docebo to review, Docebo simply loads the package exactly as Rise configured it — keeping the navigation locked. As noted in Docebo's SCORM management documentation, the LMS relies entirely on the package's internal settings for internal navigation logic.
In organizations I've worked with, the pattern that holds up best to solve this is adjusting the build in Rise:
-
In your Rise Theme settings, change the overall Course Navigation from Restricted to Free.
-
Immediately below your required knowledge checks, insert a Continue block.
-
Edit the Continue block and set the Completion Type to Complete Block Directly Above.
This forces learners to successfully interact with the knowledge checks to move forward the first time. However, because the overarching course navigation is "Free," they can jump around seamlessly when they return to review the content later.
Happy to share more detail if it helps.
Where Knowledge Checks are located, we have set the Completion Type to Complete Block Directly Above. Knowledge Checks do not require a correct answer to continue. We have set free Navigation in both Rise 360 and Docebo. After completing the course, when we click on “retake the lesson” some of them are complete and others are “reopened”.
+1Thanks for the clarification, Thammo. If the navigation is already set to Free and the Continue blocks are configured correctly, this behavior points to a data communication constraint.
In organizations I've worked with, when Rise course progress behaves erratically upon return, saving some block completions but "reopening" or resetting others—we typically look at two main culprits: session timeouts and SCORM data limits.
1. Session Timeouts (Very common with knowledge checks): If a learner leaves a knowledge check open and idles for an extended period, their background Docebo session may time out. When they finally click forward, the SCORM package attempts to send an LMSCommit (save) action to a connection that is no longer active, resulting in lost progress for that specific block.
2. The SCORM 1.2 Data Limit: Rise tracks progress at a highly granular level, recording data for nearly every block. SCORM 1.2 strictly limits bookmarking data (suspend_data) to 4,096 characters. Content-heavy courses easily exceed this limit, causing the LMS to stop recording new progress data reliably. If you're using SCORM 1.2, republishing as SCORM 2004 (3rd or 4th Edition) or xAPI often resolves this completely.
To see exactly what bookmarking data Docebo is actively receiving and where the communication drops off, you can review the specific SCORM CMI tracking logs by checking the User Statistics tab within the Course Report.
Log in to Docebo Community
Enter your email address or username and password below to log in to Docebo Community. No account yet? Create an account
Docebo Employee Login
or
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.