InfoCapture notifications are a really important part of the workflow and configuration of InfoCapture forms, it can be frustrating if they are not appearing to work in the way you were expecting.

In this article, we are going to cover tips and tricks for locating or understanding why notifications are missing and also why unexpected notifications may have arrived.

Locating the cause of a missing notification

1- Verification that the notification did or did not send

If you are running Claromentis 8.8.9+, we added additional tracking for InfoCapture notifications within the audit log.

Admin > Audit log > View logs:

If you can locate a submitted ticket which you would have expected to produce a notification, you will need to cross-reference the time the notification should have triggered with the time range selected in the audit.

If the notification did send but was not received it means:

• Your form is functioning correctly
• The email left the system but did not (for some reason) reach the inbox of the user
  • Was the email address correct / could the email be in spam or junk
  • If we host your site, you can submit a support ticket and we will check the SMTP server to see if the email has bounced or is blocked for any reason
  • If you are self-hosted (on-premise) you may wish to check your SMTP server to trace why this email did not reach the inbox

If you do not have access to the additional audit tracking you may need to check the SMTP setting to see if there were any blocked messages or it could mean there is something wrong with the form.

2 - Is the form correct

If the notification did not appear in the audit tool at all - it means the form is not configured correctly.

In this scenario the customer support team did not get a notification that a new ticket was submitted, it is best to work backwards from the notification itself. When looking at the notification configuration these are the two key questions: 

1 - Is the trigger correct?

If we check back to the trigger configuration, it all seems correct:

If this trigger is based on a field condition set, this will also need checking. You will then need to ensure every condition that was identified within the field condition set was definitely met when the user submitted the ticket. 

2- Does this role have permissions to view tickets?

When a specific role is entered into the notification configuration (rather than a direct email for example) the system will run a check to ensure that 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. 

Checking the permissions, we can see the 'Customer support' role is missing this permission:

Locating the cause of an unexpected notification

If you have a notification arrive which you do not see configured in the notification panel, this could indicate one of the following scenarios.

1- If the recipient of the notification was either the ticket submitter or ticket handler - are either of these boxes ticked:

Having either of these ticked will result in the handler or submitter receiving a default notification. If you wish to customise the default notification, here is some guidance. 

2 - A second place to look (if the above are not checked) is in the front end of the InfoCapture in the ticket list view. You will need to ask the user who is getting these notifications to check whether any of these settings are checked:

3- You will need to ensure that the users are definitely not included in any of the roles that are due to get notifications, a way of checking this is by reviewing the template of the notification. If you know the subject line of the email is 'A new Bug issue reported....' you can check who is in line to receive this notification, in the example below:

You would then need to double-check that the user who received this notification is not in the 'Development' role.