If you find your end-users are not receiving email notifications, there are a number of steps you can take to determine the cause for the notification failure.
The following approach can help you get to the root of the problem. We recommend trying these suggestions in the order listed below, which follows the standard approach our Support staff takes when assisting you with notification issues.
These procedures specifically address triggers, but the same steps would apply when troubleshooting automations:
This article contains the following topics:
- Determining ticket events
- Issue: User doesn't have an email address
- Issue: Trigger deactivated
- Issue: Trigger conditions not met
Determining ticket events
The first task when troubleshooting failed email notifications is to determine if Zendesk attempted to send a message and was not able to, or if the trigger failed and the attempt was not made.
If you find an example ticket where customers don't seem to be receiving messages, you can check the audit trail (see Viewing all events of a ticket) to see what happened.
To view a ticket's audit trail and locate the notification event
- View the ticket, and open the audit trail by clicking the Conversations drop-down and selecting Events.
- In the Events view, scroll to the comment update that should have notified the customer, and look for a notification event like this:
This indicates that Zendesk attempted to send a message to this customer. If you see a notification event but the customer did not receive it, encourage them to check their Spam folder and/or contact their mail administrators to see if something is held up in a queue somewhere. Our support team should also be able to assist in gathering message-tracking information for recent messages if those mail administrators would like a message-ID and timestamp.
If you aren't seeing a notification event, it may be due to one of the reasons described in the following sections.
Zendesk only attempts to send emails to customers who have an email address. Check the profile of the user in question to ensure that their email address hasn't been removed or modified - that it's the same address at which they're expecting the message.
If the user has multiple email addresses, Zendesk attempts to notify the Primary email address, regardless of the address the customer used when reaching out.
If your end-users aren't receiving any of your comment updates on tickets, be sure to double check that your default triggers aren't disabled. See About the Support default triggers for information about your default triggers and why they are important.
To confirm that your default triggers are firing
- Click the Admin icon ( ) in the sidebar then go to Business Rules > Triggers:
This means that each time you change the status, your reply is not sent to the requester. There are three default triggers that notify customers of updates to their ticket:
- Notify requester of received request: will automatically notify an end-user as soon as their request has been turned into a ticket within your Zendesk.
- Notify requester of a comment update: will update your end-user when a public comment has been posted to their ticket.
If there was an active trigger (as described above) at the time of this update that you expected to fire, look at the conditions of that trigger.
One area that can lead to confusion is the condition "Ticket is updated". This condition does not take place at the time of ticket-creation. If you'd like a trigger to fire at that time as well, you'll need to include the condition "Ticket is created".
Be sure that conditions are in the correct part of the trigger, placing them into the "Meet ANY of the following conditions" section will be far more lenient than the "Meet ALL" section. This can be both good and bad, so plan your triggers accordingly.
If it looks like the current trigger conditions should have applied to the ticket update in question, is it possible that those conditions have changed? At the top of the trigger-editing page should be a timestamp indicating when this trigger was last updated. If that timestamp is more recent than the update to the ticket, it's possible that the conditions were different at the time the ticket update was made.