Using centralised notifications

Accessing the notification configuration page

There are various ways to access the centralised notifications configuration page in Totara:

• To configure notifications that occur at the site level, or that will be inherited by lower contexts, go to Quick-access menu > Notifications.
• To configure notifications at the tenant level, see Configure tenant-specific notifications.
• Notifications can be configured in specific instances, such as courses, activities, programs, certifications, performance activities, etc. Typically you can access the notifications for these instances via a link in the administration blocks, or a Notifications tab. See Feature-specific notifications to find out more about accessing notifications at lower context levels.

Regardless of the context in which you access the notifications configuration page, the functionality provided on the page is the same, with a small number of additional configuration options available when configuring notifications at the site level.

Notification triggers

Once on a notification configuration page, you can expand the relevant category to see a list of all notification triggers. If the context you are in only contains notification triggers relating to one category then the list of notification triggers in that category will already be displayed.

See the following pages for more information:

• Enable and disable notification triggers
• Configure notification delivery channels

Configuring notifications

Click a notification trigger to expand it and see the notifications relating to that event. Each notification trigger can have multiple notifications assigned to it. For example, by default the Learner assigned in certification event has two notifications - one that goes to the user, and one that goes to the user's manager.

The notification's Type indicates where it comes from, and determines some actions that can be performed with that notification in the current context:

• Factory: When viewing notifications at the site level, this indicates that the notification is a built-in notification. These notifications can be modified or disabled in this context, but they cannot be deleted.
• Custom: Indicates that the notification has been created in the current context. They can be fully controlled in this context and can only be deleted in this context.
• Inherited: Indicates that the notification is inherited from a higher context. These notifications can be modified or disabled in this context, but they cannot be deleted.

See Notification settings for more information on each of the configurable settings for notifications. 

See the following pages for more information on configuring notifications:

• Configure notification delivery channels
• Create a new notification
• Configure individual notifications
• Edit a notification
• Delete a notification
• Notification settings
• Configure tenant-specific notifications

Notification inheritance and templates

The centralised notification system does not provide templates in the traditional sense, but you can set up notifications in a way similar to having templates. Notification inheritance and overrides can be used when you require notifications that will be reused in many (but not all) contexts where a given notification event is applicable.

For example, say that many (but not all) courses on a site require a notification to be sent one month after completion. At the site level, an administrator can create the notification. They can define the recipients, schedule, subject and body to be used in all applicable courses. They can then set the status to Disabled, meaning it will be disabled in lower contexts by default. Then in each applicable course, the Editing Trainer can simply edit the inherited notification, override the status, and enable the notification. The Editing Trainer can also customise the notification as required for each course.

Use of text editors

The Weka editor is the default text editor when creating or editing a notification unless it is disabled on your site. If the Weka editor is disabled you can instead select either the Plain text format, HTML format or Markdown format from the dropdown menu above the text editor. 

Notification emails are sent containing both an HTML version and plain-text version of the notification content, and email clients (not Totara) choose which version of the email content to display. Typically clients should use the HTML version. Depending on which editor you use, the notification content is converted into HTML and plain-text in slightly different ways.

When you use the Weka editor, the content is stored in the JSON format, and is converted to HTML or plain text when the notification is sent. You're limited to the formatting options that are provided by the Weka editor. If you want full styling control then you will need to use the HTML editor, which allows you to format the output however you want. The HTML is used as is when generating HTML output, but the HTML will be stripped out when generating the plain-text output. If the plain-text editor is used, then the plain text will be used for both the HTML and plain-text version of the email, so they'll both look the same, with no formatting.