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 new notification service, the old [calendar_attachment] shortcode is no longer used. Instead, you can now add calendar attachments using a selector in the user interface.
When existing notifications containing the old shortcode are migrated to the new service, the system will automatically remove [calendar_attachment] from the message body and add the new calendar attachment.
Consequently, you may need to manually review and adjust the message body of notifications that previously used this shortcode. For example, a sentence like "Calendar link for the session: [calendar_attachment]" will become truncated to "Calendar link to the session: "
In such cases, you should revise the sentence to something like "The calendar link for the session is attached to this message."
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 recipient, 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 notifications targeting deleted courses
After the transition to the new notification engine, you may find that some of your pre-existing migrated notifications are now targeting a broader audience than they were before, and unexpectedly being sent out to a large number of users.
If this happens, the cause may be a migrated notification that targets deleted or inactive courses. Such a notification in effect has no content filters applied (because all the targeted content was deleted or deactivated)
- In legacy notifications, a notification with no content filters did not get sent out.
- In the new notification service a notification with no content filters (if saved by a Superadmin) will be triggered for all courses and learning plans in the platform.
Recommended action: Review any migrated notifications that may have previously targeted deleted or inactive courses. These notifications may now be interpreted as global (unfiltered) and could be delivered more broadly than intended.
For more information see the Community post on this topic (opens in a new tab).
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.
Migration of ‘User subscribed to a group’ notification
In legacy notifications, the ‘User subscribed to a group’ notification did not apply the branch trigger filters.
As a result, when both group and branch triggers were specified, the notification would still fire whenever any user was added to one of the specified groups–regardless of their branch.
In new notifications, branch trigger filters are now also applied, using AND logic. This means the notification will only fire when a user who belongs to one of the specified branches is added to one of the specified groups.
For more details about the logic of this notification see the article Notification events and conditions > User subscribed to a group notification.