Dynamic rules Configuration

This feature is part of Moodle Workplace™, which is available through Moodle Certified Partners and Service Providers only.

Managing dynamic rules

You can access the management of dynamic rules through Site administration > Dynamic rules or directly via the Dynamic rules icon in the Workplace launcher.

For each rule the following information is shown:

Enabled / Disabled icon
Name of the rule
Scheduled task and Shared space labels (optional)
Tags that have been applied to the rule
Specified rule Conditions
Specified rule Actions
Apply on: Date when the rule was applied for the first time (the label Future is displayed for date later than today)
Created: Rule's creation date
Actions:
- Duplicate dynamic rule
- Archive dynamic rule
- View report

The process for creating a new dynamic rule is as follows:

Add a new rule clicking the +New rule button
Specify the rules header
Add one or more rules conditions
Add one or more rules actions
Enable the rule

Rules header

The rules header serves as a descriptive wrapper for all elements of the rule body and includes the following options:

Name: This does not need to be unique, but it is recommended to give each rule a unique and meaningful label.

Rule action limits: This option defines the maximum number of times the actions can apply. Once users meet the rule conditions, the actions will be applied. These actions will not apply again if users continue to meet the conditions. However, if a user stops meeting the conditions and then matches them again, the actions may be applied once more. This setting specifies the maximum number of times actions should (re-)apply. Once the Rule action limits setting is enabled, you can choose from two options to limit the number of times the matching process occurs:

Can't be applied more than X times ever
Can't be applied more than X times per Y minutes/hours/days/weeks/seconds

The rule action limits feature allows you to control how often a rule's action can be triggered:

No rule action limits is the default setting and should be used when you cannot predict when conditions will be met and when immediate actions are expected. For example, the successful completion of a course may trigger the award of a competency or badge.

The ever matching mode is preferred when you know that a condition will only be met a certain number of times. For instance, this is useful for issuing a certificate to all users who completed an archived course after migrating historical data.
The per matching mode is beneficial if a delay in executing the action is acceptable. For example, notifying a manager after a team member has attended a seminar does not need to happen immediately and is usually sufficient once a day.

If the Include suspended users option is enabled, the rule will evaluate the conditions for users whose accounts have been suspended. Keep in mind that some actions may not fully apply to suspended users; for example, they will never receive notifications.

Tags: To organize and categorize your rules, you can select or enter tags.

Start date: The selected start date marks the beginning for evaluating the rule. Events affecting conditions, such as "course completed," can occur at any time before or after the selected date.

End date (optional): The selected end date serves as the fixed deadline for evaluating this rule.

These user-defined time frames let you schedule dynamic rules to run in the future.

Rule conditions

Conditions represent the IF part of a dynamic rule.

On the Conditions tab, you will find a listing of predefined conditions for each entity that can be evaluated to trigger actions. Each condition has its editable properties; for example, using the drop-down menu lets you select a course that has to be completed, as well as the completion date and time parameters.

Some conditions support the selection of multiple entities, most of which support the configuration of the Criteria when several entities have been selected:

All criteria have been met: actions are triggered when all selected items are satisfied
At least one criterion has been met: actions are triggered only once, that is when the second item is satisfied, actions will not be triggered again
Every time the criterion has been met (coming soon): Equivalent of creating multiple rules, one for each item

Only those conditions that the current user has the capability to add are listed. Some conditions may be listed but not available, which is the case if no entities associated with the condition exist in the system; for instance, the "Course completed" condition can only be added if there is at least one course the user (dynamic rule creator or editor) has rights to see users within.

Once the conditions part has been configured, click on Save Changes. You can always return later and change the settings of your rules using the Edit condition or Delete condition icons. If users have previously matched rule conditions, the conditions part becomes read-only. Actions can be edited at any point.

Modification or removal of conditions and actions from other users requires appropriate editing capabilities. For example, if one user adds the condition "User enrolled" and another user does not have access to this particular course, the condition will be read-only, indicated by the lock symbol. If a rule is invalid and processing is not possible, the broken condition or action can be modified or deleted without the required permissions. At the bottom of the tab, you can check how many users would meet these conditions. By clicking on the View matching users link, you can view the complete user listing.

Most dynamic rule conditions are event-based, which means that when a particular requirement is matched (for example, “Course completed”), the event will trigger the rule. However, some conditions are not activated by events but run as a scheduled task. For example, if you want to perform an action upon users who did not complete a course, the condition "Course not completed" will instead scan the courses periodically (on cron run), looking for users that match this condition. If the system finds one or more users that match this condition, the rule will be triggered.

General conditions

This category contains conditions based on cohort membership, course completion and enrolment, and user-related criteria.

Condition name	Setting(s)	Multi-select	Scheduled	Prerequisites
User is member of cohort	Cohort <cohort> Added to cohort on or after this date and time <datetime>	No	No	Cohort has to exist Permission to view cohort
User is not member of cohort	Cohort <cohort>	No	Yes	Cohort has to exist Permission to view cohort
User has achieved competency	Select competency <competency>	No	Yes	Competency has to exist Permission to view competencies
Course completed	Course <course> Completion date Any time After <datetime> Before <datetime> Course grade Any Less than <percentage> Greater than <percentage> Range <percentage_from> <percentage_to>	No	No	Course has to exist Permission to see at least one user
Course last access	Course <course> The user's last course access Ever Never Before <datetime> After <datetime> During the last <period> Prior to the last <period>	No	Yes	Course has to exist Permission to see at least one user
Course not completed	Course <course> This condition is applied to users regardless of their enrolment on the course.	No	Yes	Course has to exist Permission to see at least one user
Time since user was created	Creation date During the last <period> Prior to the last <period>	No	Yes	Capability to view user details
User enrolled	Course <course> Enrolment method <enrolment> Enrolment start date and time is on or after <datetime>	No	No	At least one course has to exist Permission to view participants in course
User first login	The user's first login was Not set (initial setting; cannot be selected) Range <start date> <end date> During the last <period> Ever (user has logged on sometime in the past) Never (user has an account but has never logged in)	No	Yes	Capability to view user details
User last login	The user's last login was Not set (initial setting; cannot be selected) Prior to the last <period> During the last <period> Ever (user has logged on sometime in the past) Never (user has an account but has never logged in)	No	Yes	Capability to view user details
User not enrolled	Course <course> Enrolment method <enrolment>	No	Yes	At least one course has to exist Permission to view participants in course
User profile field	Profile field with type-specific matching operations. Custom profile fields are fully supported.	No	No	Capability to view user details For custom fields, the visibility status has to be set to "All"

Certifications

This category contains conditions based on certification-related criteria.

Condition name	Setting(s)	Multi-Select	Scheduled	Prerequisite
Certification certified	Certification <certifications> Criteria All of the selected certifications have been certified At least one of the selected certifications is certified Every time a user is certified in any of the selected certifications (Not available yet) Certified date on or after <datetime> Option to configure the execution of action-related recertifications Only execute actions when the user status changes from "not certified" to "certified" Always execute actions on all re-certifications	Yes	No	Certifications have to exist Permission to allocate users Permission to edit certification
Certification expired	Certification <certification> Expired date on or after <datetime>	No	Yes	Certifications have to exist Permission to allocate users Permission to edit certification
Certification not certified	Certification <certification>	No	Yes	Certifications have to exist Permission to allocate users Permission to edit certification
Certification overdue	Certification <certification> Due date on or after <datetime>	No	Yes	Certifications have to exist Permission to allocate users Permission to edit certification
Certification suspended	Certification <certification> Suspended date on or after <datetime>	No	No	Certifications have to exist Permission to allocate users Permission to edit certification
Recertification grace period ends	Certification <certification> Recertification grace period ends on or before <datetime>	No	No	Certifications have to exist Permission to allocate users Permission to edit certification
Recertification period started	Certification <certification> Recertification started on or after <datetime>	No	No	Certifications have to exist Permission to allocate users Permission to edit certification
Users allocated to certification	Certification <certification> Allocated date on or after <datetime>	No	No	Certifications have to exist Permission to allocate users Permission to edit certification
Users not allocated to certification	Certification <certification>	No	No	Certifications have to exist Permission to allocate users Permission to edit certification

Organisation structure

This category contains conditions dealing with jobs, departments and positions.

Condition name	Setting(s)	Multi-Select	Scheduled	Prerequisite
User is in department	Department <departments> Include subdepartments Criteria User has jobs in all of the selected departments User has a job in any of the selected departments Every time a user gets a job in any of the selected departments (Not available yet) Job start date is on or after <datetime>	Yes	No	Departments have to exist Permission to assign jobs
User is manager	Any Select Manager Manager (assigned manually) Department lead	No	Yes
User is not in department	Department <departments> Include subdepartments	Yes	Yes	Departments have to exist Permission to assign jobs
User has position	Position <positions> Include subposition Critiera User has jobs in all of the selected positions User has a job in any of the selected positions Every time a user gets a job in any of the selected positions (Not available yet) Job start date is on or after <datetime>	Yes	No	Positions have to exist Permission to assign jobs
User doesn't have position	Position <positions> Include subposition	Yes	Yes	Positions have to exist Permission to assign jobs

Program

This category contains conditions based on program criteria.

Condition name	Setting(s)	Multi-Select	Scheduled	Prerequisite
Program completed	Program <programs> Criteria All of the selected programs have been completed At least one of the selected programs is completed Every time a user completes any of the selected programs (Not available yet) Completion date on or after <datetime>	Yes	No	Programs have to exist Permission to allocate users Permission to edit program
Program not completed	Program <program>	No	Yes	Programs have to exist Permission to allocate users Permission to edit program
Program overdue	Program <program> Due date on or after <datetime>	No	Yes	Programs have to exist Permission to allocate users Permission to edit program
Program suspended	Program <program> Suspended date on or after <datetime>	No	Yes	Programs have to exist Permission to allocate users Permission to edit program
Users allocated to program	Program <program> Allocation date on or after <datetime>	No	No	Programs have to exist Permission to allocate users Permission to edit program
Users not allocated to program	Program <program>	No	No	Programs have to exist Permission to allocate users Permission to edit program

Multi-tenancy

This category contains conditions based on tenant criteria (see also information on Cross-tenant Dynamic Rules). It will only appear in dynamic rules in Shared space.

Condition name	Setting(s)	Multi-Select	Scheduled	Prerequisite
Users allocated to tenant	Tenant <tenant>	No	No	Only available in Shared Space
Users not allocated to tenant	Tenant <tenant>	No	No	Only available in Shared Space

Note: when a multi-tenancy condition is used and you wish to allocate Courses in the Rules Actions section, you can only select courses that are available across tenants.

Rule actions

Conditions represent the THEN part of a dynamic rule.

In the Actions tab, you will find a list of actions that will be executed once the previously defined conditions have been met. You have to pick an element from the list of actions and configure its properties to add actions.

Only those actions that the current user has the capability to add are listed. Some actions may be listed but not available, which is the case if no entities associated with the actions exist in the system; for instance, the "Award badge" action can only be added if there is at least one badge on your system.

General actions

This category contains general actions not belonging to any particular category.

Action name	Setting(s)	Prerequisite
Award badge	Select badge <badge>	Badges have to exist Badge criteria has to be set to “Manual issue by role” Permission to issue badge
Issue certificate	Select certificate <certificate> Expiry date Never Select <datetime> After <period>	Certificates have to exist Permission to issue certificate
Add to cohort	Cohort <cohort>	Cohorts have to exist Permission to add users to cohorts
Remove from cohort	Cohort <cohort>	Cohorts have to exist Permission to remove users from cohort
Award competency	Select competency <competency>	Competencies have to exist Permission to award competency Note that this action is not available to tenant admins.
Delete users	None (Actions deletes all affected users)	Permission to delete users
Assign learning plan	Select learning plan <learning plan>	Learning plans have to exist Permission to assign learning plan (core/competency:planmanage) Note that this action is not available to tenant admins.
Un-assign learning plan	Select learning plan <learning plan>	Learning plans have to exist Permission to assign learning plan (core/competency:planmanage) Note that this action is not available to tenant admins.
Notification	Subject: title of notification to be sent out Body: Message text in HTML, including images and notification placeholders Send to Matching users Department lead Manager Manually assigned manager Notifications will be sent directly to the user and their direct department lead(s) or manager(s), respectively. That is, leads and managers higher up in the hierarchy will not be sent any notifications. Multi-language content is fully supported for notifications.	Permission to send messages
Suspend users	None (Actions suspends all affected users)	Permission to suspend users
Unsuspend users	None (Actions unsuspends all affected users)	Permission to unsuspend users

Notification placeholders

A range of placeholders can be used in the notification body; these placeholders will then be replaced with the appropriate values when the message is sent. All placeholders are enclosed in double curly brackets, for example {{userfullname}}.

The placeholders available in the message's body change depending on the conditions that have been selected. To see the list of available placeholders, you need to expand the Available placeholders list.

The table shows all the message placeholders, grouped by condition category (including prerequisites):

Condition category (Prerequisite)	Notification Placeholder	Description
Users (always available)	{{username}}	Username
	{{useremail}}	Email address
	{{userfirstname}}	First name
	{{userfullname}}	Full name
Site (always available)	{{sitefullname}}	Full site name
	{{siteshortname}}	Site short name
	{{sitelink}}	Site link
	{{sitelinkspecific}}	Site link specific for the tenant
Courses (Course completed, Course not completed)	{{courseid}}	Internal course ID used in URLs
	{{coursefullname}}	Course full name
	{{courseshortname}}	Course short name
	{{courseurl}}	Course URL
	{{coursecompletiondate}}	Course completion date
	{{coursegrade}}	Course grade
	{{coursecustomfield_<name>}}	Course custom field
Programs and Certifications (any programs or certifications condition)	{{programid}}	Internal program ID used in URLs
	{{programname}}	Program name
	{{programcompletedcourses}}	Courses completed in program
	{{programcompletiondate}}	Program completion date
Certifications (any certifications condition)	{{certificationid}}	Internal certification ID used in URLs
	{{certificationname}}	Certification name
	{{certificationdate}}	Certification date
	{{certificationexpirydate}}	Certification expiry date
	{{expirydatetimestamp}}	Certification expiry date timestamp
	{{certificationreopen}}	Recertification start date
	{{certificationprogramname}}	Initial program name for this certification
	{{recertificationprogramname}}	Recertification program name
	{{certificationgraceperiodend}}	Grace period end date
User enroled	{{courseid}}	Internal course ID used in URLs
	{{coursefullname}}	Course full name
	{{courseshortname}}	Course short name
	{{courseurl}}	Course URL
	{{coursecustomfield_<name>}}	Course custom field

Multi-language support in notifications

Both, the Subject and the Body fields support multi-language content. The Multi-language content filter has to be enabled and configured to allow notifications in multiple languages. Once activated, the Multi-language content filter supports the <span lang="xx"class="multilang"> tag, where xx represents the language pack code, for example, en for English or de for German.

Notifications will be sent in the recipient's language. Thus, if a German speaking manager has an Italian speaking team member, the manager will receive the message in German while the team member will receive the message in Italian. Using multi-lingual notifications can also cater for cultural idiosyncrasies such as calling staff in by first name in some countries and by surname in others.

Multi-language support in notifications also works with the Multilang2 plugin which some institutions might prefer over the built-in multi-language content filter.