Business Rules
Business rules define how assignments are assigned, when assignments appear on a Learning Plan, and when a course is considered valid, or overdue. The decision diagram below shows the steps used when an assignment is added to a user or an existing assignment for a user is edited. While assignments may be added/edited for an audience, the business rules are applied on a user-by-user basis.
A user receives a new assignment in one of 3 ways:
- The user is added to Compliance for the first time and inherits all courses assigned to new hires
- A new course is assigned to the user or audience by the administrator
- A new attribute is assigned to the user which creates a new audience association and the user inherits the audience assignments.
In cases 2 and 3, the course assigned to the user may be a more stringent version of an existing course assignment. In these cases, the overriding requirement is determined following the stringency rules (see Stringency section for more details), and the business rules are then applied to that requirement.
Likewise, the business rules may be re-applied to a user if
- The User Information for that user is edited (including through data uploads)
- The most stringent assignment already assigned to that user is edited.
Regardless if it is a new assignment or a reprocess of an existing one, the first check is for a valid completion (either current or historical). A completion is considered valid if the completion date is in the time period “today” (the day the assignment is made) minus the validity or retraining period.
Example:
John Doe completed Bloodborne Pathogens on 12/15/2016, and was subsequently removed from the demographic group having this requirement. At that time, his completion is moved to the completion log table-- in other words, it was “pushed to history.” On 5/1/2017, John Doe was again placed in a demographic group requiring Bloodborne Pathogen training. The course is required annually (valid for 1 year). “Today” is 5/1/2017, minus validity of 1 year, equals 5/1/2016. His completion of 12/15/2016 falls between the dates of 5/1/2016 and 5/1/2017; therefore, his previous completion is valid. This completion is then resurrected and linked to the new requirement.
If a previous valid completion does not exist, the training will be assigned to the user as Initial Training following the initial training decision associated with the most stringent requirement.
There are obvious loopholes which must be managed in these rules. For example, during the “open for retraining period” if a training assignment is edited by an administrator, it would not be useful to resurrect and link the previous completion, which is still valid until the next due date. Therefore, a check is made if “today” is in the retraining window for the user. If so, a valid completion is not resurrected and linked. Likewise, a check is made if the completion being linked to a requirement has a completion date in the “retraining window” for that requirement. If so, the completion is linked to the current requirement including the requirement’s due date.
Example:
John Doe completed Back Safety on 12/15/2017 with a due date of 12/31/2017, but the requirement was subsequently removed from his requirement list. As a result, the 12/15/2017 completion was pushed to history. John Doe is then placed in another demographic group with the same course due on calendar date 1/15/2018 (RDD). The “Open for retraining” period of the new requirement is 60 days. John Doe’s previous completion of 12/15/2005 is in the window of retraining for this requirement (1/25/2018 – 60 days =~11/25/2017), so the completion is linked to this requirement and the associated due date for that completion is updated to 1/15/2018 (versus 12/31/2017).
In a similar example, John Doe completed Back Safety on 8/1/2017, and the requirement was subsequently removed from his list. As a result, the 8/1/2017 completion was pushed to history. On 12/15/2017, John Doe is added back to a group requiring Back Safety on 1/15/2017. His previous completion is valid, but “today” is in the retraining window of the requirement. If his completion is resurrected and linked to the new requirement, it would simply get pushed back to history the following night during the nightly processing, because this course is due again (as RDD) on 1/15/2018. Therefore, to prevent this cycle of linking and pushing, the system recognizes the situation and simply creates for John Doe a new requirement with the 1/15/2018 due date, leaving his previous completion in history.
Finally, in the case where neither the completion nor “today” are in the retraining window, the completion will get linked as expected. Here, John Doe completed the course on 8/1/2017, and the requirement was subsequently removed. On 10/2/2017, he was placed in the training group requiring Back Safety as RDD due on 1/15/2018. His completion is valid; the completion is not in the retraining window for the requirement; and today is not in the retraining window for the requirement. His previous completion is resurrected, but the previous associated due date (12/31/2017) is left in place. On the date when the new requirement should open for training (1/15/2018 – 60 days, or ~11/15/2017), the previous completion is pushed back to history, and a new requirement assigned to John Doe, due 1/15/2018.
These examples assume an RDD assignment because RCD assignments do not have a due date associated with the requirement itself. The due date for RCDs will either be based on the user’s last completion date, or if no last completion date exists or is invalid, the due date will be based on the Initial Training decision for that assignment.
In all cases, an Exemption, Equivalency or “other” course completion function just as WBT completions. A “valid equivalency” may actually serve in place of a “valid completion.” Each of these is checked during the decision process.
Another case which may be tricky is the case of existing, overdue training. When a user is in retraining mode (meaning this is not their initial assignment for a course) and the user has become overdue for that assignment, a subsequent edit or add of an assignment would place the user in Initial Training (because the previous completion is now invalid). Therefore, a flag is checked for requirements having no valid completion to determine if that requirement is a retraining situation. If so and the requirement is overdue, the due date of the requirement is not modified regardless of the assignment change. All other assignment parameters (training type, validity, test out, passing threshold, etc.) will be updated. (Please see Stringency section above regarding the override of overdue training through the use of Individual Training Assignments.)
Flow Chart
