When a learner enrolls in an ILC Session it is possible to not select a Session resulting in potential confusion, the ability to configure a required session enrollment will ensure learners select a Session and have a complete enrollment
I'm glad to see part of the problem was solved, but the fact that users can still enroll themselves in these ILC "shells" when there aren't any sessions available is still a problem for us. If there was a toggle that can be turned on/off on ILCs to allow/disallow this, that would be awesome! Also echoing the others, the issue with these ILCs attached to curricula is another pain point.
I'm hoping that Absorb will continue to improve this functionality.
I want to add that testing the Next Generation Learner Experience, the problem still remains with unenrolled sessions if the Learner signs up via a Curriculum.
If you click Enroll from the catalogue, the button changes to Start
And you realise that the learner still haven't chosen any sessions. So essentially this feature for us is still missing, as ALL of our courses have to be created via Curriculums as you today are unable to add SCORM packages to an ILC learning course.
How are the odds that you will make the experience "atomic" for Curricula too? If there is a session that the learner must chose, should not be able to be in a stated of enrolle until ALL sessions are properly signed up for.
I've chatted with our CSM Natalie on this. There still remains one challenge. Admins can still assign people to the course without choosing a session. Now while we heard it was intended this way, the problem rests with users having "no session" selected.
When users are allowed to rest in this state, they pose a substantial risk. While they get an email with instruction to select a session, we have a long culture of 2 paths: user selected attendance or admin. When admin's do it, it's believed the work is all done. THey'll get the date/time/invite to go. I would highly suggest you put a block feature on the "save" button to force the admin to pick a session.
Glad to see the update coming. We've done a substantial amount of user testing with our network and the UX element that is always described is that once they hit enroll for the ILC/ILT container, they think they're "in". Now for those who gauge (as we do), we use the actual sessions themselves far in advance.
So if we setup a set of cycles of sessions and open enrollments, we can see if people have interest. That allows us to keep or cancel a session. We're extremely happen to see the forced enrollment coming.
We do however have clients that require a) enrollment in an ILC only to gauge interest before they define sessions (please see previous comments below) as well b) allowing their learners the flexibility to cancel a session that might be occurring within the immediate future that they no longer can attend. We will work to refine on these edge case workflows in the future, and I will certainly reach out for further discussion.
For the July release, we will address the most immediate pain point to require session selection (if one or more exists) at the time of ILC enrollment. That is, they will be an atomic action and using your analogy, the learner will be required to purchase a plane ticket at the time of confirming their interest in going to the airport (i.e. in the ILC).
This was our initial idea thread as this feature is something main to one aspect to our Absorb use. Main thing is to focus on the user experience. When they enroll, the ILC and the "session" are in respect redudant. They believe to just enroll once. So I would honestly remove the ability to enroll in an ILC and in a sense, use only session enrollments. If you have one session, enroll. Multiple, select one.
Now in regards to un-enroll, it should function that if the feature to dis-allow un-enrollments is on, that is what it is. If they allow for un-enrollment, it should do both the session/ILC. But my reference above about removing the idea of enrolling in an ILC would fix that.
If you stand back for a second and think, why would someone enroll in a "shell" being the ILC, it doesn't make much user sense. They're actually there to enroll in a session. It would be like buying a ticket to the airport, but in reality, you want a plane ticket. Just my 2 cents. Feel free to reach to me at james.lavis@kubota.com
Hello everyone. We are in the midst of implementing this workflow requirement to require session selection upon ILC enrollment (except in the edge use case where an admin explicitly does NOT define any sessions and wants to gauge interest in the ILC alone...see previous comments below). Having worked through our existing logic, we are confident we can satisfy the session mandatory selection at the time of initial ILC enrollment.
However, we are facing complexities with the ability to deliver this new requirement in combination with your other admin available configuration settings of:
a) Learner Self-Unenroll, and
b) Prohibit Learners From Changing or Cancelling Sessions
so we are thinking we will still afford a learner to "Cancel Session" after enrollment (when the "Prohibit Learners From Changing or Cancelling Sessions" setting is OFF). That is, this will create situations where your learners could be enrolled in ILC and not a session; however, we think we get 90% of the way there with the requirement to select a session upon initial ILC enrollment to reduce your administrative overhead.
Agree with the comments that we should either have a setting to require a user to enroll in a session in an ILC or skip the enrolling in the ILC portion and just enroll in a session.
This looks to be on "the roadmap" - when is this targeted for release / deployment?
I'd just like to add that an admin enrolling a learner and then leaving the session select process up to them should stay separate from the learner selecting an ILC and being forced/heavily encouraged to select a session immediately. I'm otherwise pro immediate session selection, because we see the same behavior in our learners enrolling in an ILC and thinking they are done.
Im a bit with Rebecca, We have some ILC where we''ll only have it as a one and done. But others, we might have a number if sessions, but have only one scheduled, so we wouldn't want everyone enrolling in the one session when we will be adding more. But we do want people to enroll in the ILC as it helps inform the level of interest and helps determine how many sessions we might need.
A "choose session" nudge, might go a long way too, knowing there is a data point for "no session selected" on the reporting side.
We have the same issue with users believing they are signed up for a session, when they really only enrolled in the ILC course. We spend a lot of time logging in to address this issue when our users don't enroll correctly, and of course it always happens when the class is starting and they realize they don't have the sign in information because they never received a confirmation email because they didn't sign up for a session (which is the only time they get one from us). So then its an emergancy and my staff and I have to drop everything to deal with it right then. This happens to us all the time. I agree that the admin burden with the current functionality is too large. If forcing enrollment in a session wouldn't work, can we consider a pop up asking them to complete enrollment by selecting a session with an option to opt out and chose later? Then at least they would know they aren't fully enrolled.
My opinion is that this should be a setting for admins to select while creating an ILC and not necessarily forced, since there are clients that do not want to force a user to enroll in a session.
For our company, we have would want the ability to require a session to be selected when enrolling in an ILC. Otherwise, as other people have mentioned in this thread, the users who only enroll into the ILC and not a session believe that they are actually signed up for a session.
I'm going to go against a few folks here. We do hundreds of these and the biggest issue is someone enrolling in the ILC and thinking they are done. They are not forced to choose a session. So we get the joy of trying to reach out to them and get them to go back in. In theory, it makes no sense to have someone simply enroll in the "shell" of the ILC. You want them to join a session. At Kubota, we do an insane number of these events, we absolutely need an option to toggle or force a user to enroll in a session. I honestly don't believe you need an "enroll" in the ILC shell, you need only an "enroll" button in the session.
I want to reiterate our team's earlier votes and comments that the ability to enroll in an ILC without selecting a session is the #1 loophole we need fixed by Absorb. We manage tens of thousands of enrollments annually for ILCs, and chasing down customers to identify which session they need to attend is not sustainable. Thank you for optimizing for the majority of customers on this thread who want to see this change made.
Thanks everyone for your feedback. Connor, might you expand on your use case that you don't want this streamlining and assurance of enrollment into a session as an atomic part of enrolling into an ILC? That is, are you speaking from an admin workflow perspective or for a learner? Can you tell us more how making this an atomic action would complicate your process? thank you.
I disagree that a session should be required in order to enroll in an ILC. Sometimes it is necessary to simply enroll someone without immediately assigning them a session. If this ability was removed it would complicated some processes.
There is a user experience challenge in the implementation of this feature as it currently sits. The end goal is for a person to enroll in a session, that's what we all want.
Fundamentally, if a person "enrolls" in an ILC event, they believe they are done. A trigger goes off in their head that they've made it. That works ONLY if you have one session. How do I know this from our few thousand users? They only enroll in the parent ILC and not a session, so we get the joy of trying to reach out and track them down, causing substantial admin time.
The best UX fix I see is to have the ILC event as the shell, with no enroll button. Have them enroll in a session. People do not undersrtand the difference between enrolling in an ILC AND a session. It's redundant to them. I cannot stress how bad we as a large corp need that first button removed.
Hi Demetrio. We use waitlists depending on a session or a course. That being said, might I suggest that self-enrollment into a ILC should be prevented unless there is 1) at least one session available for enrollment that they'll need to enroll in or 2) at least one session available with waitlists spots. just an idea.
I'm glad to see part of the problem was solved, but the fact that users can still enroll themselves in these ILC "shells" when there aren't any sessions available is still a problem for us. If there was a toggle that can be turned on/off on ILCs to allow/disallow this, that would be awesome! Also echoing the others, the issue with these ILCs attached to curricula is another pain point.
I'm hoping that Absorb will continue to improve this functionality.
I would like to echo Soren's comments. All of our ILCs are attached to Curriculums and therefore do not prompt the user to enroll in a session.
I want to add that testing the Next Generation Learner Experience, the problem still remains with unenrolled sessions if the Learner signs up via a Curriculum.
If you click Enroll from the catalogue, the button changes to Start
And you realise that the learner still haven't chosen any sessions. So essentially this feature for us is still missing, as ALL of our courses have to be created via Curriculums as you today are unable to add SCORM packages to an ILC learning course.
How are the odds that you will make the experience "atomic" for Curricula too? If there is a session that the learner must chose, should not be able to be in a stated of enrolle until ALL sessions are properly signed up for.
Hey Demetrio,
I've chatted with our CSM Natalie on this. There still remains one challenge. Admins can still assign people to the course without choosing a session. Now while we heard it was intended this way, the problem rests with users having "no session" selected.
When users are allowed to rest in this state, they pose a substantial risk. While they get an email with instruction to select a session, we have a long culture of 2 paths: user selected attendance or admin. When admin's do it, it's believed the work is all done. THey'll get the date/time/invite to go. I would highly suggest you put a block feature on the "save" button to force the admin to pick a session.
We have released changes in July to require learners to choose a session, if a future one is available or has a waitlist, at the time of enrollment. Please see https://support.absorblms.com/hc/en-us/articles/7542148445459-July-Release-Notes-and-Details-2022#ilc-session-enrollment-0-5 as well as https://support.absorblms.com/hc/en-us/articles/7594935408915#01G7CW0YTDKTFNRHEBXVRFQEAD , and thank you again for your idea!
Thanks Demetrio,
Glad to see the update coming. We've done a substantial amount of user testing with our network and the UX element that is always described is that once they hit enroll for the ILC/ILT container, they think they're "in". Now for those who gauge (as we do), we use the actual sessions themselves far in advance.
So if we setup a set of cycles of sessions and open enrollments, we can see if people have interest. That allows us to keep or cancel a session. We're extremely happen to see the forced enrollment coming.
Thank you James for your detailed comment.
We do however have clients that require a) enrollment in an ILC only to gauge interest before they define sessions (please see previous comments below) as well b) allowing their learners the flexibility to cancel a session that might be occurring within the immediate future that they no longer can attend. We will work to refine on these edge case workflows in the future, and I will certainly reach out for further discussion.
For the July release, we will address the most immediate pain point to require session selection (if one or more exists) at the time of ILC enrollment. That is, they will be an atomic action and using your analogy, the learner will be required to purchase a plane ticket at the time of confirming their interest in going to the airport (i.e. in the ILC).
Hey Demeterio,
This was our initial idea thread as this feature is something main to one aspect to our Absorb use. Main thing is to focus on the user experience. When they enroll, the ILC and the "session" are in respect redudant. They believe to just enroll once. So I would honestly remove the ability to enroll in an ILC and in a sense, use only session enrollments. If you have one session, enroll. Multiple, select one.
Now in regards to un-enroll, it should function that if the feature to dis-allow un-enrollments is on, that is what it is. If they allow for un-enrollment, it should do both the session/ILC. But my reference above about removing the idea of enrolling in an ILC would fix that.
If you stand back for a second and think, why would someone enroll in a "shell" being the ILC, it doesn't make much user sense. They're actually there to enroll in a session. It would be like buying a ticket to the airport, but in reality, you want a plane ticket. Just my 2 cents. Feel free to reach to me at james.lavis@kubota.com
Hello everyone. We are in the midst of implementing this workflow requirement to require session selection upon ILC enrollment (except in the edge use case where an admin explicitly does NOT define any sessions and wants to gauge interest in the ILC alone...see previous comments below). Having worked through our existing logic, we are confident we can satisfy the session mandatory selection at the time of initial ILC enrollment.
However, we are facing complexities with the ability to deliver this new requirement in combination with your other admin available configuration settings of:
a) Learner Self-Unenroll, and
b) Prohibit Learners From Changing or Cancelling Sessions
so we are thinking we will still afford a learner to "Cancel Session" after enrollment (when the "Prohibit Learners From Changing or Cancelling Sessions" setting is OFF). That is, this will create situations where your learners could be enrolled in ILC and not a session; however, we think we get 90% of the way there with the requirement to select a session upon initial ILC enrollment to reduce your administrative overhead.
Agree with the comments that we should either have a setting to require a user to enroll in a session in an ILC or skip the enrolling in the ILC portion and just enroll in a session.
This looks to be on "the roadmap" - when is this targeted for release / deployment?
I'd just like to add that an admin enrolling a learner and then leaving the session select process up to them should stay separate from the learner selecting an ILC and being forced/heavily encouraged to select a session immediately.
I'm otherwise pro immediate session selection, because we see the same behavior in our learners enrolling in an ILC and thinking they are done.
Im a bit with Rebecca, We have some ILC where we''ll only have it as a one and done. But others, we might have a number if sessions, but have only one scheduled, so we wouldn't want everyone enrolling in the one session when we will be adding more. But we do want people to enroll in the ILC as it helps inform the level of interest and helps determine how many sessions we might need.
A "choose session" nudge, might go a long way too, knowing there is a data point for "no session selected" on the reporting side.
We have the same issue with users believing they are signed up for a session, when they really only enrolled in the ILC course. We spend a lot of time logging in to address this issue when our users don't enroll correctly, and of course it always happens when the class is starting and they realize they don't have the sign in information because they never received a confirmation email because they didn't sign up for a session (which is the only time they get one from us). So then its an emergancy and my staff and I have to drop everything to deal with it right then. This happens to us all the time. I agree that the admin burden with the current functionality is too large. If forcing enrollment in a session wouldn't work, can we consider a pop up asking them to complete enrollment by selecting a session with an option to opt out and chose later? Then at least they would know they aren't fully enrolled.
My opinion is that this should be a setting for admins to select while creating an ILC and not necessarily forced, since there are clients that do not want to force a user to enroll in a session.
For our company, we have would want the ability to require a session to be selected when enrolling in an ILC. Otherwise, as other people have mentioned in this thread, the users who only enroll into the ILC and not a session believe that they are actually signed up for a session.
I'm going to go against a few folks here. We do hundreds of these and the biggest issue is someone enrolling in the ILC and thinking they are done. They are not forced to choose a session. So we get the joy of trying to reach out to them and get them to go back in. In theory, it makes no sense to have someone simply enroll in the "shell" of the ILC. You want them to join a session. At Kubota, we do an insane number of these events, we absolutely need an option to toggle or force a user to enroll in a session. I honestly don't believe you need an "enroll" in the ILC shell, you need only an "enroll" button in the session.
I want to reiterate our team's earlier votes and comments that the ability to enroll in an ILC without selecting a session is the #1 loophole we need fixed by Absorb. We manage tens of thousands of enrollments annually for ILCs, and chasing down customers to identify which session they need to attend is not sustainable. Thank you for optimizing for the majority of customers on this thread who want to see this change made.
Thanks everyone for your feedback. Connor, might you expand on your use case that you don't want this streamlining and assurance of enrollment into a session as an atomic part of enrolling into an ILC? That is, are you speaking from an admin workflow perspective or for a learner? Can you tell us more how making this an atomic action would complicate your process? thank you.
I disagree that a session should be required in order to enroll in an ILC. Sometimes it is necessary to simply enroll someone without immediately assigning them a session. If this ability was removed it would complicated some processes.
There is a user experience challenge in the implementation of this feature as it currently sits. The end goal is for a person to enroll in a session, that's what we all want.
Fundamentally, if a person "enrolls" in an ILC event, they believe they are done. A trigger goes off in their head that they've made it. That works ONLY if you have one session. How do I know this from our few thousand users? They only enroll in the parent ILC and not a session, so we get the joy of trying to reach out and track them down, causing substantial admin time.
The best UX fix I see is to have the ILC event as the shell, with no enroll button. Have them enroll in a session. People do not undersrtand the difference between enrolling in an ILC AND a session. It's redundant to them. I cannot stress how bad we as a large corp need that first button removed.
Hi Demetrio. We use waitlists depending on a session or a course. That being said, might I suggest that self-enrollment into a ILC should be prevented unless there is 1) at least one session available for enrollment that they'll need to enroll in or 2) at least one session available with waitlists spots. just an idea.