Overview

🚧

Feature not available in sandbox mode after the organisation is live.

The Customer notifications tooling is shared between sandbox and production. Organisations with live operational use are not able to access this feature in sandbox mode, and any changes made will be live. For new product modules, the Customer notifications tooling can be used in production mode.

Root supports automated email and SMS notifications for a range of standard policy and other lifecycle events. You can also create your own custom events, which can be triggered from the product module code or via the API. Read more about how to configure your own custom events in the custom notification events guide.

For each event, an email and/or SMS notification can be enabled or disabled separately.

To view the available notification events, and to start configuring notification templates for your product module, head to the "Customer notifications" tab under the "Workbench" menu on the Root management dashboard.

Configuring email and SMS templates

📘

Add links to policy documents in notifications

You can add links to policy documents in the body of email and SMS notifications using the tracked document link handlebars helper.

Email and SMS templates are customised for each event. Email templates are configured in MJML, and you can dynamically inject policy and policyholder information into the message body for both email and SMS using handlebars. These templates also allow you to configure the email subject and sender details like the "from" and "reply to" email addresses. You can define organisation-wide layout templates to re-use the same header and footer layouts and branding across different email templates.

The notifications configuration is product specific. For each product module you can enable or disable different events, and use different message templates.

🚧

Master templates vs. product module specific templates

Root enables you to define master templates that apply across all your organisation's product modules.

Note: If you disable a notification that uses as master template for one product module, that notification will also be disabled for other product modules in your organisation that use the same master template.

To disable an event for one specific product module without affecting your other product modules, make sure to use a product module specific template.

Email notifications and attachments

Email notifications for certain events include attachments. You can read more about the different policy documents, how to configure templates for them, and when they are first generated in the policy documents guide.

The tables below show which documents are attached to standard notification events. For custom notification events, you can configure which attachments are included in the email for each event.

📘

Not all emails include attachments

The events listed under the following categories do not include attachments: payment events, claim events, and complaint events.

Standard policy events

The following policy events are not currently supported, and are excluded from the table: covered people updated, sum assured updated, policy requoted. We recommend disabling these events.

Standard payment Method events

Standard application events

Additional email recipients

The default email recipient depends on the notification event type. For example, policy event emails are sent to the policyholder by default.

You can add additional email recipients by editing the email template for a specific notification event. For example, you can configure all "Policy issued" emails to be sent to [email protected] in addition to the policyholder. A separate notification will be created for each additional recipient

🚧

Using handlebars to generate multiple email addresses

Please note that only one additional email address can be added per additional recipient. In other words, a comma-separated list of email addresses cannot be generated using handlebars. If more than one additional recipient needs to receive the email, each address should be defined as a separate recipient.

You can use handlebars to specify recipient email addresses dynamically based on policy-specific data. The resulting email address is compiled using the same merge variables available to the body of the email.

Below is a video to show how additional email address can be added.