New article
Recently updated
Troubleshooting external users not receiving automated workflow email notifications
Who is this article for?
Administrators troubleshooting email notification delivery.
System Administration permissions are required. IT or email security team involvement may be needed.
If external users such as committee members, lab partners, or customers stop receiving automated workflow email notifications while internal users continue to receive them normally, the issue typically involves two separate parts of the email delivery chain that need to be checked independently.
This article explains how to perform the troubleshooting effectively.
Issue
When internal users receive notifications but external users do not, the issue is rarely with the workflow configuration, as the same automation sends both. The problem usually lies further along the delivery path, either after the emails leave the system or before they reach external inboxes.
| Problem | Description | Responsible party |
|---|---|---|
| Sending side | A server-side issue is preventing emails from being generated or sent correctly to certain recipients | Ideagen Support |
| Receiving side | Your organisation's email security or filtering system is not trusting the sending address and is silently blocking or rejecting incoming emails | Your IT or email security team |
Important
Both causes may occur simultaneously. Fixing the sending-side issue alone might not suffice if your organisation's email security still blocks the emails. Both ends of the delivery chain usually need checking.
Troubleshooting
When reporting this issue, gather the following information:
- Email addresses of the affected external users
- Whether these users have received automated emails successfully in the past, or if this is a new account
- Whether internal users in your organisation are receiving emails successfully
- Approximately when the issue started
- Whether any recent changes were made to your system, such as a platform migration
Note
If the issue began sometime after a migration or platform change, it doesn't rule out the migration as a cause. Configuration problems from the migration, like incomplete rollbacks, may only appear after a later trigger.
Solution
If we confirm there is no issue on the sending side, or after any sending-side issue has been resolved, your organisation's email security or filtering system should be checked next.
To resolve the issue on the receiving side:
- Verify if the sending IP for system emails is whitelisted or trusted in your email security settings.
- Ensure system emails are authorised as trusted senders for your domain.
- Check if your email security silently rejects untrusted emails instead of bouncing them, which may make it seem like no email was sent.
Example
An organisation's email security gateway only accepts mail relayed from a trusted list of IP addresses. After a system migration, the application's outbound emails come from a new, unlisted IP.
Internal users are unaffected as their mail bypasses external filtering. However, external recipients' mail systems silently reject these emails without sending bounce notifications.
Tip
Conduct a small test by sending a notification to a few affected external recipients after any changes. Confirm receipt with each recipient individually, as silent filtering won’t produce bounce messages you can verify.