Notifications are a crucial part of many InfoCapture projects, so it can be frustrating if these do not appear to work in the way you were expecting.
This guide will cover how an administrator can investigate when a user reports that they have not received a notification from a ticket as they expected.
You will need to be an application administrator of Infocapture, the Audit log and People to follow all the guidance.
Please review our article on creating Infocapture notifications, as this covers how to set these up so they can fire as expected and not be prevented by conflicts or other form logic, as well as our guide on the audit log.
I. Confirm a notification was generated
A user has reported they did not receive a notification to their inbox/in system messenger from a ticket when x occurred (and they expected this to, or it did in the past)
e.g. they were assigned to the ticket, the status of the ticket changed, a field in the ticket was edited, etc
A. Gather required information
- The ticket ID
- Confirm which user(s) expected to receive the notification but didn't
- Confirm which trigger is sending the notification that was not received
These are listed in Admin > IC > Your form > Notifications
- Confirm what format the trigger will send the notification in (Email or in system message, configured in the trigger itself)
- Identify the date & time that the trigger was met in the ticket and should have fired to generate the notification.
Depending on what the trigger is, an easy way to get the timestamp against certain changes made to a ticket is by checking its history tab.
e.g. A user did not receive a notification tied to a status change. So, I need to confirm the status was actually changed. This is shown in the 'History' tab of a ticket.
- Identify if the date/time of the change we are interested in is within or outside the value set in the audit log.
Audit log information is archived after a certain timeframe, as per the value set in Admin > Audit > configure audit (30 days by default)
Check what this value is set to on your site to understand the timeframe the audit log can be searched in the Intranet.
e.g. If the value on your site is 30 days, but the notification you are looking for was triggered 50 days ago, you cannot search for the audit log for records in this period in the system. Instead, you need to find the appropriate archived log and download these to search for the action you are interested in instead.
B. Use the gathered information to search the audit log
Follow the instructions below based on your scenario and the information gathered to confirm if the notification was recorded in the audit log and therefore sent.
1. If the notification you are looking for was triggered within the timeframe...
a) ...and is an email
- Open Admin > Audit log > View logs
- Change the date information to the date (and time if necessary) that you know the trigger should have been met on or around.
- Select 'Infocapture' and 'Send notification as an email'
- Click 'Filter' and then 'Download to a CSV'. The file will be downloaded to your computer.
- Open the file locally
- Delete any columns that are not providing helpful data for the investigation
- Search the file for references to the ticket ID (Control or Command + F)
- Click through these until you have confirmed whether the notification was recorded at the corresponding date/time the trigger should have fired
- e.g. the below - The trigger for the email was a ticket being submitted. Pippa F submitted a ticket, so two rules based on this trigger fired, one sending an email to Pippa and one sending an email to Phil L. The system has recorded both emails being sent:
b) ...and is an in-system message
- Open Admin > Audit log > View logs
- Change the date information to the date (and time if necessary) that you know the trigger should have been met on or around.
- Select 'Infocapture' and 'Send notification as an in-system message'
- Click 'Filter' and then 'Download to a CSV'. The file will be downloaded to your computer.
- Open the file locally
- Delete any columns that are not providing helpful data for the investigation
- Search the file for references to the ticket ID (Control or Command + F)
- Click through these until you have confirmed whether the notification was recorded at the corresponding date/time the trigger should have fired
- e.g. the below - The trigger for the in-system message was a ticket being submitted. Brian M submitted a ticket, so two rules based on this trigger fired, one sending an in-system message to Brian and one sending messages to the project role 'Admin', which includes Nigel D and Claro admin. The system has recorded both messages being sent:
2. If the notification was triggered outside the timeframe
- It does not matter if the trigger would send an in-system message or an email; both can now only be searched for within the archived logs.
- Audited actions will be saved to an archived log depending on the value set in Admin > Audit > Configure log (default is 30 days), so check what this is for your site
- Based on the title of the archived logs, identify the appropriate one to search for the notification you are looking for in Admin > Audit > Archived log (the one that contains the date information that matches when the trigger you are interested in would have fired)
- Download the file and open it locally on your computer
- Delete any columns that are not providing helpful data for the investigation
- Search the file for references to the ticket ID (Control or Command + F)
- Click through these until you have confirmed whether the notification was recorded at the corresponding date/time the trigger should have fired
- You may need to search multiple archived files to find the correct date/time and confirm if the notification was recorded.
- e.g. The trigger I am interested in would have fired 40 days ago, and on my site, the log archives after 30 days. Therefore, I need to check the most recent archived log and search for the ticket I am interested in to confirm if it has been recorded as having been sent.
II. Next steps
Now that you have confirmed whether the notification was recorded in the audit log or not, follow the next steps that correspond to your situation.
A user reports that they did not need to receive a notification from a form...
A. as an email to their inbox
- If the email has been recorded in the audit log but not received, this indicates the issue is with your mail server, preventing its delivery.
Next steps:
- Ask the user to check if the email is in their spam or junk folder
- Confirm that the email address on the user's Intranet account is entered correctly
- If you are self-hosted (on-premise), your IT department can search for further information about the email on their mail server and comment on how to prevent further non-deliveries to that user's address.
- If your site is hosted by us (SaaS) raise a support ticket, and we will check the mail server for an indication that the mail was not delivered.
- If the email is NOT recorded in the audit log, this confirms its generation was prevented due to an issue in the configuration of the form.
Next steps:
- Form administrators need to investigate the project, confirm what prevented the trigger from firing and make changes to resolve this.
- Follow the guidance given here
B. as an in-system message to the Intranet messenger
- If the notification being triggered has been recorded in the audit log, this should appear in the system messenger.
Next steps:
- If the notification cannot be seen in the messenger, please raise a support ticket for us to assist further.
- If the notification is NOT recorded in the audit log, this confirms its generation was prevented due to an issue in the configuration of the form.
Next steps:
- Form administrators need to investigate the project, confirm what prevented the trigger from firing and make changes to resolve this.
- Follow the guidance given here
III. Investigate your project & make a change
Your IC administrators will need to investigate the IC project to check that it is set up correctly to allow the notification trigger to fire (and nothing in the logic is blocking this from occurring)
There are caveats for notifications being generated, which are detailed in our 'Creating IC notifications' guide.
The most common reasons an email does not trigger as expected:
- The recipient does not have 'view tickets' rights in the project role they are in
The system will never send a notification to a user who cannot view the ticket, even if the notification rule has been created
- The field condition set used in the trigger was not actually met
For a trigger to fire, its conditions must all be met. If one part is not, the notification will not fire.
- Multiple triggers were met at the same time and for the same recipients
The system will only send one notification to a user, even if multiple are triggered at the same time. This is to prevent spam, and the notification that will be sent is the one listed highest in the order.
Open the notification rule area for your form (Admin > Infocapture > your form > Notifications)
Three questions need to be answered for the rule you are investigating, and will usually reveal why the notification did not fire.
Solutions are provided for each.
A - Did the trigger fire?
If the field conditions or trigger used in a notification rule are not met, it cannot fire.
Most investigations will reveal an issue with the trigger that can be rectified to allow the notification to fire next time.
Most commonly, this is because its conditions were not actually met as first thought.
Identify the name of the trigger used in the rule you are interested in in Admin > IC > Your form > Notifications:
Find the same trigger in Admin > IC > Your Form > Triggers
Check that its contents are as you would expect, and would have been fulfilled in the ticket you are investigating when you expected the notification to be sent.
e.g. The 'Status changed' trigger below includes the 'Any of these fields changed' option for status, and in my scenario, I know the status was changed, so I would expect the notification to fire successfully.
However, if a trigger is based on a field condition or includes one, this has to be checked as well to ensure it can also be met and allow the trigger to fire.
Head to the 'Field conditions' tab to see what is specified in any conditions used in the trigger.
e.g. Below the trigger also contains a condition:
So we need to check what exactly this captures to ensure it has also been met in our scenario, and allowed the trigger to fire to send the notification:
If a new ticket was submitted, but the selection made in the 'severity' field was not 'major', this trigger will not have fired.
It's expected that the notification tied to it did not send for this reason, as not all its conditions were met.
Solution
Evaluate the trigger you are interested in and confirm that it is set up correctly to be able to fire and would have fired in your scenario.
The result should allow your administrators to either update the trigger and its conditions in the rule to allow it to be met, or decide if a change needs to be made to the form to allow its conditions to be met more readily.
B - Does the recipient's role have permissions to view tickets?
When a specific role is entered into the notification rule (rather than a direct email, for example) the system will run a check to ensure that the project role has permissions to view tickets.
As notifications often contain ticket details, it would be a permissions loophole if roles placed here could get notifications without the 'view tickets' permission.
Head to and check that the role the user is investigating the notification for has 'view tickets' permission - either a custom project role or one of the hardcoded roles e.g. submitter, ticket handler.
If not, this is why the notification is not being sent and recorded in the audit log.
Solution
Your administrators will need to consider giving the project role the user is in 'view' tickets' rights to allow the notification to send, or change their requirements.
The usual solution here is to give the 'submitter' role 'view tickets' rights but not the custom role the user is in, which ensures they can be notified about their own tickets but will not see/be notified about anyone elses.
C - Is there a conflict between multiple notification rules?
Check the rules in the notification area and cross-reference the recipient, triggers and conditions involved to confirm if multiple would have fired at the same time as the rule you are interested in.
Any conflict will need to be rectified to ensure the notification rule you want to fire for that change sends.
If another rule exists that is also being met at the same time for that user, the system will send one notification, and this is the highest in the order.
Solution
Changing the order may resolve the situation for the notification you are interested in, but this does not resolve it for the rule moved lower.
How can you resolve the conflict?
Usually, this is done by changing the field conditions within one of the rules to allow them to fire at different times.
The appropriate change will depend on your needs for your form.
