Skip to main content

Docebo Help

How can we help?

Transition to the new notification service

Last updated
Docebo module
Reading time
User level
  • Administrators

Introduction

This article provides information about the transition to the new notification service, including:

  • Answers to frequently asked questions
  • Notable differences compared to legacy notifications
  • Considerations pertaining to porting of pre-existing notifications

For the main documentation of the new notification service see the knowledge base articles: 

Configuring notifications
Shortcodes in notifications
Notification events and conditions

For information about the rollout schedule see the community post: New Notification Service Rollout: Gradual Release Plan | Community. 

Porting of existing notifications

With the migration to the new notification engine, existing notifications will be carried over automatically, so that in most cases you do not need to take any manual actions. But consult the rest of this article for some points that you might want to check.

Shortcode syntax

Previously, the shortcodes that you inserted into the message body were delimited by square brackets, for example [course_link]. 

In the new notifications, all shortcodes are instead delimited by double curly braces, for example: {{course_link}}.

When your platform is migrated to the new notification service, the shortcodes in your existing notifications will be automatically converted to the new syntax. So you do not need to manually adjust anything.

Base URL for links in notifications

With the transition to the new notification service, the system automatically inserts into notification links the correct base URL for each recipient. This means that:

  • Each person receiving a message containing a shortcode such as {{course_link}} will get a link that targets their specific extended enterprise client. 
  • There is no need to configure separate versions of a notification for each extended enterprise client. 
  • The base URL of a notification is no longer affected by its type of scheduling, or by who edits or saves the notification.

For more information see the article Shortcodes in notifications >  Shortcode links and extended enterprise domains. 

Calendar attachment shortcode

With the migration to the new notification engine,  the [calendar_attachment] shortcode is replaced by a selector in the user interface that allows you to add an attachment. As a result you will need to manually adjust the body of the notifications that use this shortcode.

Learner has completed a learning plan notification

For those using the Learner Has Completed A Learning Plan notification triggered by the users belonging to a branch with Power Users or Superadmins as receipient, with the migration to the new notification engine, recipients now receive notifications only for users belonging to the triggering branch. They will no longer receive notifications for any platform user completing the learning plan.

Porting of notification schedules

In the new notification service, the Scheduler supports time frames within the following allowed ranges: 

Hours:  1→72 
Days:   1→365
Weeks:  1→52 
Months: 1→24 

Legacy scheduled notifications with time frames outside these ranges will be ported applying the following conversion rule:

Convert the value to the next unit of measurement until a permitted value is reached. For example:

73 hours → 4 days
371 days → 53 weeks → 13 months

The Time is always set to 00:00 (corresponding to 12am) according to the defined timezone.

Any notifications with a time frame that exceeds 24 months (for example 200 weeks) will not be migrated. 

Accordingly, after migration of your pre-existing notifications you may want to adjust the time frame obtained as a result of the conversion and set a different time of day when the notification is sent out.

Incorrect shortcodes in migrated templates

Only for sandbox platforms that were first migrated to the new notification service in December 2024, due to an issue with some message templates, the following notification types need to be checked and manually adjusted:

User Has Been Created (By Administrator)
User Has Been Created (Confirmed Registration)
New Privacy Policy Version
New Question To Expert

More specifically, pre-existing notifications based on the affected templates may contain incorrect shortcodes such as:

{{firstname}} → should be {{first_name}}
{{lastname}} → should be {{last_name}}
{{password}} → should be {{user_password}}

Or they may contain shortcodes that are not listed among the allowed ones for that notification even.  For example: {{firstname}} when the notification event only allows {{username}}.

Please note: This issue does not affect platforms that were first migrated to the new notification service in January 2025 or after that time. It only affects those sandboxes that were initially migrated in December 2024, and subsequently rolled back.

What to do:

If your platform is among those potentially affected, you need to:

  • Check any pre-existing notifications of the affected event types, and manually correct any wrong shortcodes. The allowed shortcodes and their correct syntax are as shown in the Shortcodes section of the message composition area.

Tip: The issue only affects the pre-existing notifications, of the affected event types, that were migrated from legacy. The templates have subsequently been fixed, so when you create new notifications of these types the shortcodes will be correct.

Migration of extended enterprise notifications

If you have migrated extended enterprise notifications, depending on how these were configured you may be affected by the following change in the recipients and trigger scope: 

In legacy notifications, the triggers and recipients of a notification were automatically restricted to the users of the extended enterprise client where that notification was configured and saved. This would happen even if no branch filter was set.
As a result, you could configure:

  • Multiple versions of the same notification, each one targeting the users of a different extended enterprise client. 
  • This could be achieved without a branch filter, simply by saving each notification in the appropriate extended enterprise client. 

With the new notification service, the triggers and recipients of a notification are no longer restricted to the extended enterprise client where the notification is saved. So if you have migrated notifications configured as described above, some users may now receive duplicate notifications. 

You can correct this in two ways:

  • Method 1: add branch filters Keep the multiple versions of the same notification, but insert into each one the appropriate branch filter, corresponding to the extended enterprise client that it should target. 
  • Method 2: use a single notification  Replace the multiple versions of the same notification with a single notification that will work for recipients belonging to all extended enterprise clients. Remember that any shortcode links will automatically use the correct base URL for each recipient. You can also use the {{extend_enterprise_logo}} shortcode to dynamically insert the correct platform logo.  

 Example: In legacy notifications, you configured: 

  • User enrolled in a course with no branch filters, saved on domain A: The notification is triggered only by users belonging to domain A, and sent only to recipients belonging to domain A
  • User enrolled in a course with no branch filters, saved on domain B: The notification is triggered only by users belonging to domain B, and sent only to recipients belonging to domain B.  

After migration to new notification service, both these notifications can be triggered by a user belonging to any domain, and will be sent out to recipients belonging to any domain. So a user enrolling in a course will trigger and receive both notifications A and B.