Click here to watch the video full screen.

Auto Enroll involves setting targets beforehand and a mechanism to check if the user matches any of the set targets afterward that would trigger the actual enrollment. The checking mechanism could take a toll on system resources if it's required to check all active users on the system against all the courses that have preset targets. Such bulk actions should not be performed that often and the frequency can be configured as mentioned below.

A complete comparison would be for each user, check all the courses with targets to see if the user has attributes that match with any of the targets. But is it necessary to do this each time as we need to contemplate the costs of resources in doing this? Thus, timestamp is recorded on the user side as well as on the course side so checking will be done only if conditions are met based on timestamp comparisons for the resource-optimizing mode setting.

On the user account, there is a timestamp to record when was the last auto-enroll scan as shown below:

If you click Save on the user account, regardless of whether any change has been made on the account, as any change could potentially affect target matching in the auto-enroll checking process, it would change this timestamp value to 'unknown'.

On the course setting, there is a timestamp to record when the auto-enroll targets last changed as shown below:

This records when the administrator last clicked 'Set Auto-Enroll Targets' which could potentially alter targets that may target a different group of audience.

Now the following conditions would trigger the corresponding actions in the resource-optimizing mode:

1. If a change has been made in the user account and the last auto-enroll scan timestamp is unknown then this account will be checked against all courses with targets.

2. If the course target activation timestamp is more recent than the last auto-enroll timestamp that means the course targets have been changed after the user account's attributes were set. So this user will be checked against this course.

3. If the course target activation timestamp is earlier than the last auto-enroll timestamp which means the course targets remain the same after the user has been scanned then there is no need to check this user against this course.

In order to picture how the actual checking works, there is a user queue to put the users in. For online checking, when a user logs in, it puts that user in the queue. For offline checking, the event handler would put the group of users in the queue. The other queue would be what courses should be scanned against and be put in the course queue which would depend on one of the three conditions mentioned above.

Click here to watch the video full screen.

There are different option settings to configure how auto-enroll should be run for the system in the Auto-Enroll Console. Selecting the most appropriate settings that weigh checking completeness against resource optimization for the desired outcome.

Let's take a look at the upper section which deals with scan interval setting that is applicable for both online checking & offline checking:

This setting will affect what courses to be put in the course queue, essentially it is equivalent to clicking the set targets button for every course:

 

Only When Criteria or User Attributes Change

• This is the resource-optimizing mode that we've been talking about before.

At Every Login

• All courses with targets will be put in the course queue only when a user logs in.

Each Week

• All courses with targets will be put in the course queue each week by the event handler.

Each Month

• All courses with targets will be put in the course queue each month by the event handler.

Let's take a look at the lower section which deals with putting users in the user queue via the event handler:

For online checking, a user is put in the user queue when that user logs in. For offline checking bulk checking, a group of users is being put in the user queue depending on the frequency set:

Trickle Option

• This would divide the total number of active users on the system by 30 then put the portion of users in the user queue via the daily event handler. In terms of which courses to check against, this would depend on the option set in the upper section.

 

All Active Users Per Day

• This would put all active users in the user queue via the daily event handler. In terms of which courses to check against, this would depend on the option set in the upper section.

 

All Active Users Per Week

• This would put all active users in the user queue via the weekly event handler. In terms of which courses to check against, this would depend on the option set in the upper section.

 

All Active Users Per Month

• This would put all active users in the user queue via the monthly event handler. In terms of which courses to check against, this would depend on the option set in the upper section.

 

A common misconception is that all users will be checked against all courses with targets in the offline checking coupled with the option below, for example:

This combination will only put all users in the user queue to be scanned against courses that have been recently changed in the course queue but it won't put all courses with targets to be against all users every day for completeness. Note that there is no daily option here and this is intentional because such a complete scan should not be done every day as it takes a toll on the resources for the system.

For a complete scan, this can be done weekly or monthly only as the following weekly combo will ensure that no users will miss the auto-enroll scan at least to have everything covered at least once on a weekly basis.

Common Auto Enroll Failures

******************************

 

Auto Enroll errors spotted in the log:

 

Severity(ERROR) Source(com.netdimen.core.AutoEnrollManager.attemptEnrollment): AutoEnroll Failed for xxx in course_xxx:EKP000105537, Status=2

2 means Pending Approval. This means that the target course has a Approval Step(s) in the Enrollment Policy that it's currently using. Auto-enrollment will not going to work to any courses that has an Approval Step(s) in their Enrollment Policy

 

Severity(ERROR) Source(com.netdimen.core.AutoEnrollManager.attemptEnrollment): AutoEnroll Failed for xxx in course_xxx:EKP000105537, Status=3

3 means Security Approval. This means that the option This module/program currently allows public access is unchecked under Define Enrollment Policy of the target course in Catalog Editor. The said option needs to be checked in order to resolve the error.

Severity(ERROR) Source(com.netdimen.core.AutoEnrollManager.attemptEnrollment): AutoEnroll Failed for xxx in course_xxx:EKP000105537, Status=8

8 means Already Enrolled. This means that the target user(s) currently has an active enrollment (with either a Not Started or In Process overall status) on the target course.