Introduction
This article explains how to investigate and resolve common notification issues in the platform, including notifications that are not sent, delayed, duplicated or delivered to the wrong recipient. It also covers how to test notifications safely and what information to gather before contacting support.
Before you start troubleshooting
Gathering the following details before you begin will help you resolve the issue more efficiently, and will be required if you need to contact support.
| Information to gather | Details |
|---|---|
| Notification type | Email or in-platform |
| Specific notification | For example: course |
| Expected time and date | When the notification should have been triggered |
| Affected users | Usernames or email addresses involved |
| Evidence | Screenshots or message samples, if available |
How to test a notification
Best practice: Notifications can have a real effect on recipients. Do not use real, active users or live resources when testing.
When testing a notification, create dedicated dummy resources to use in place of live ones. Depending on the notification type, you may need some or all of the following:
- a dummy course or learning plan
- a dummy user
- a dummy Superadmin
- a dummy Power User
- a dummy channel
- a dummy group
- a dummy branch
Associate the notification only with your dummy resources before testing. Do not assign it broadly before you have confirmed it is working as expected.
To trigger the notification, perform the action that launches it.
Example: If the notification is for a course enrollment, enroll your dummy user in the dummy course
If you are unsure which action triggers a specific notification, refer to Notification events and conditions.
Once you have triggered the event, verify delivery by checking the test user's email inbox and their in-platform notifications area. Allow a few minutes, as some notifications may be queued. As a Superadmin, you can also check the notification log to confirm the notification was triggered and sent, and review the Audit trail events details for a record of the triggering event.
Tip: If one notification type fails during testing, try triggering a different notification type to help isolate whether the issue is specific to that notification or platform-wide.
Notification not sent or not received
Work through the following checks to identify the cause.
Check the notification is active
Confirm the notification is set to active in the platform. An inactive notification will not be sent regardless of whether the trigger event occurs.
Verify the recipient configuration
Confirm that the correct user level is selected for the notification recipient, that the affected user's email address is correct in their profile, and that the user belongs to the correct groups or branches for the notification's audience filters.
Confirm the trigger event occurred
Verify that the event that should have triggered the notification actually took place in the platform. You can check this via the audit trail. For a full list of which events trigger which notifications, see Notification events and conditions.
Check the notification schedule
If the notification uses a scheduled trigger, verify the scheduled time is correct and has passed. Adjusting the scheduled time to an earlier hour can help confirm whether the notification fires correctly. Be aware that changing the schedule on an active notification may affect other users.
Review the notification log
Check the notification log to see whether there is any record of the notification being sent. If no record appears, the notification was not dispatched from the platform.
Check the recipient's spam or junk folder
For email notifications, ask the affected user to check their spam or junk folder in case the message was filtered before reaching the inbox.
Validate your email domain configuration
Your sender domain must be configured in Domain Management, including valid SPF, DKIM and MX records in your DNS settings. Without these records, emails may be marked as spam or rejected by the receiving mail server.
Please note: Docebo cannot investigate or provide support for email notification delivery issues when the platform is using a sender domain without SPF, DKIM and MX records configured. For setup instructions, see Domain Management: Configuring email domains.
Check your SMTP configuration (if applicable)
If you are using a custom SMTP server, verify that the hostname, port, username, password and encryption settings are correct, and that the SMTP account is authorised to send on behalf of your sender address. SPF, DKIM and MX records must still be correctly configured for your domain, according to your SMTP provider's requirements.
Invalid email error when creating a notification
When setting up a new notification, you may see the following message:
Invalid email. Please insert an email address that complies with the email security settings criteria configured in Domain management.
This error occurs because your sender domain has not been configured in Domain Management. All sender domains must be configured in this section before they can be used in notifications. Previously used domains were not automatically carried over when Domain Management was introduced and must be reconfigured manually.
To resolve this, navigate to Domain Management, add your sender domain and configure it with the required SPF, DKIM and MX records. Alternatively, you can configure the domain through the Custom SMTP Server option. For full setup instructions, see Domain Management: Configuring email domains.
Once your domain is configured, make sure you select it when setting up your notifications.
Duplicate notifications
Check for repeated trigger events
Confirm whether the triggering action was performed more than once for the same user. You can verify this via the audit trail.
Check for active integrations or automations
If your organisation uses integrations or automations that interact with the platform, these may be triggering additional notifications independently.
Learning plan and course enrollment notifications
If you have both a "User enrolled in a course" notification and a "User enrolled in a learning plan" notification active for the same audience, users enrolled in a learning plan will receive both: one notification for the learning plan enrollment and one notification for each course included in the learning plan. This is expected behaviour.
There is no built-in option to suppress course-level notifications during a learning plan enrollment. Two possible solutions are available:
- Temporarily deactivate the relevant course enrollment notifications before triggering the learning plan enrollment, then reactivate them once enrollment is complete. This requires manual coordination to avoid missing future notifications for direct course enrollments.
- Create a group for users who will only be enrolled through learning plans, and configure your course enrollment notifications to exclude that group. This approach requires knowing in advance which users will be enrolled via a learning plan rather than directly in a course.
Notification delays
Once a notification is dispatched from Docebo's mail server, actual delivery time depends on factors outside Docebo's control, including external network traffic, the receiving mail server's processing queue and the correct configuration of SPF, DKIM and MX records for the recipient's domain.
Please note: Docebo cannot investigate or provide support for email notification delivery issues when the platform is using a sender domain without SPF, DKIM and MX records configured. For more information, see Domain Management: Configuring email domains.
If the delay appears to be schedule-related, review the following guidance.
Scheduler time format
The notification scheduler uses hh:mm am/pm format (for example, 08:15 am). In this format, 12:00 am corresponds to midnight (00:00 in 24-hour time) and 12:00 pm corresponds to noon (12:00 in 24-hour time).
Hours before the event timing
The scheduler checks for events at the start of every hour. A notification will not be sent as expected if you create it within the same hour it should be sent, or if you change the event time during the hour the original notification was due to go out.
Example: If a session starts at 10:00 am and you configure a notification for 2 hours before the event, the scheduler checks at 8:00 am. If you create the notification at 8:05 am, the 8:00 am check has already passed and the notification will not be sent.
Days before the event timing
The number of days before the event does not always correspond to calendar days. Docebo calculates this as a time range: for 1 day before, the system looks for events between 24 and 48 hours away.
Example: If a session starts on Wednesday at 7:00 am and you configure a notification for 1 day before at 8:00 am, the notification sends on Monday at 8:00 am because the event is 47 hours away at that point, which falls within the 24 to 48 hour window.
To have the notification correspond to a calendar day, set the notification time to the same time or earlier than the event time.
Weeks before the event timing
The notification will not necessarily be sent on the same day of the week as the event. If the notification time is later than the event time, the notification is sent one day earlier than expected.
Example: If the event is on Wednesday at 10:00 am and you configure a notification for 1 week before at 11:00 am, the notification is sent on Tuesday of the preceding week rather than Wednesday.
Days after the event timing
If the notification time is earlier than the event time, the notification sends one day later than expected.
Example: If an event occurs on Monday at 3:00 pm and you configure a notification for 4 days after at 10:00 am, 4 days after the event is Friday at 3:00 pm, but the next occurrence of 10:00 am after that point is Saturday, so the notification sends on Saturday.
Weeks after the event timing
As with days after, if the notification time is earlier than the event time, the notification sends one extra day later than expected.
Example: If an event occurs on Monday at 11:00 am and you configure a notification for 1 week after at 9:00 am, the notification is sent on Tuesday of the following week rather than Monday.
For more information on configuring scheduled notifications, see Schedule a notification.
Notification sent to the wrong recipient
Verify that the affected user was in the correct group or branch at the time the notification was triggered, and that the correct user role was selected in the notification's recipient configuration. If any user information or group assignments were recently changed, these changes may have affected which users were in scope at the time of the trigger event.
Contact support
If you have worked through the checks above and the issue persists, contact the Docebo support team. Include the following information in your request:
| Information to include | Details |
|---|---|
| Issue description | What happened and when |
| Notification details | Type, name and configuration |
| Affected users | Usernames or email addresses |
| Evidence | Screenshots or message samples |