Group assignment to Observation Checklists

Hi, @Jeni Harrison 

I have this exact issue.  I created an automatic group and assigned it to my checklist, which was scheduled as Always available. It does attach a checklist to the Task List of each member of the group. Perfect!

But then I changed the members of the group, and incomplete checklists are NOT removed. What’s more, because the list was originally scheduled as Always available, the learners who were removed from the group continue to always have a checklist, even when they are no longer part of the group.

Sounds like a ‘bug’ to me.

Did you ever find a solution?

Morning @Jeni Harrison and @KMallette - Current state? Enrollment rules drive a function to map and not a remove a function (unmap). In other words - it is what @KMallette described in detail.

I think that is the crux of the matter and to drive a solution? You would potentially need to involve some third party manipulation with the API to support some higher level function with Obeservation Checklists.

Hi, @dklinger  … but I’m not using enrollment rules per se. I am using a Group. In other use cases where I’ve used a group, the behavior stops when the learner is no longer a member of the group. It seems “buggy” to me that this situation is different.

Thank you @KMallette. I see what you are saying - deploying OC can be done directly to a group, branch or user.  I super agree that groups and the act of enrolling need some type of expansion / revision to make it work better and feel less buggy. If/when you deploy it via groups? And you put the OC in a course container? You can leverage enrollment rules. Same if it is part of an LP. But beyond that? It is mapping the group to the OC.

That said? I believe you can play certain visibility games with the Catalog Widget to deploy an experience for a person where they are pulling the OC to themselves….but that is not necessarily what you want.

I believe there is some seriously deep consideration going on around how to revise enrollment rules right now...I hope we can all benefit from the effort.

@dklinger Here’s the back story to what I’m trying to do… as succinctly as possible.

Learner undergo periodic monitoring of their phone calls to confirm they are “following process”.
If Learner fails the review, supervisor receives a report
… here’s where the LMS comes in …
We want to prescribe retraining, manually enrolled into course or LP, but tracked with an OC.

MyTeams is in place, with the supervisor listed as the Direct Manager to the learner.

When Learner fails a review, they have an additional field marked, which adds them to an automatic group.

The OC is self-assessed, scheduled as “always available” and the group is selected.

OC appears on Learner task list, and supervisor’s MyTeams.

When Learner has completed the steps on the OC, then the supervisor approves.

Learner additional field is then unmarked to remove them from the group.

PROBLEM IS HERE: The learner continues to see new checklists on the task list even when they are not part of the group.

I kind of get it.

A question - how are they continuing to be enrolled to the OC?

Manually?

@dklinger That’s the $64 question… they shouldn’t be continuing to be enrolled in the OC. I don’t want them in the OC once they aren’t in the group.

The problem with unenrollment is it can get trickier logic wise. If things are complete does it stay? If I’m progress does it stay? What percentage of complete? Could see some very easy “oops we made a change that dropped these folks from the group and lost progress” especially with the automatic groups that seem to break fairly frequently. 

@Bfarkas Thanks for joining this conversation :-)

The OC should (and does) remain when it is In Progress because the learner is still a member of the group. I can see it on both the learner and the direct manager’s task lists.

The completed OC remains on both the learner and the direct manager’s task lists (as they should) after the learner is removed from the associated group.

The issue is that an OC (not started, blank) is still available on both task lists after the learner is removed from the associated group. This gives the impression to the learner that there is more work to be done when they don’t.

I will give a manual group a try, based on your comments with automatic groups (though I don’t think I’ve ever encountered an issue with them).

@dklinger@Bfarkas  It just occurred to me to mention that there are no courses involved with the OC, This OC is not a training material.

I did try a manual group, and had the same results after removing the learner from the group. A blank OC with a “To Do” status remained on their task list.

@KMallette  Totally get it and agree theres an issue there, was just pointing out the potential for different wants in the situation so may not be as straight forward as adds. I’ve had enough issues with automated groups that I have grown very leary of them and typically do other solutions instead for my own sanity.

Have any of you noticed that when using groups to schedule an OC (whether manual or automatic), it only assigns who is in the group at the moment the schedule is created. When I go back to add a user to the manual group and update a user profile so that they are aded to the automatic group, the new users to the groups are NOT assigned the OC. Have you experienced this? Will be logging a ticket as this basically makes using Groups in these schedules pretty useless unless they are static groups...

@lrnlab We’ve stopped using OC due to all of the group quirks… 😔

we’re still trying….battling with support about the email notifications which are also not very helpful since they dont work for users in sub domains...very frustrating to be close but still have so many little gaps everywhere...