This article explains how to troubleshoot situations where contacts appear in a rule or incident Preview Contacts list but do not receive the actual notification. Use these checks before you assume there is a delivery failure or a system-wide issue.
Overview
When you use a contact rule or incident template, the product first evaluates the rule and shows a Preview Contacts list so you can see who is eligible to receive the message. When you send, the system applies the same rule logic, but it also enforces role-based access and template settings, which can exclude some contacts even if they appeared in preview.
Because of this, discrepancies between preview and actual recipients often come from role permissions, group membership, query logic, or rule behavior, not from message delivery problems.
Step 1: Check the sending user’s role and contact access
Notifications only deliver to contacts that the sending user’s role is allowed to access, even if an org administrator can see more contacts in preview.
- Identify which user and role actually sent or launched the notification or incident.
- Open the notification template and note any groups included by the template (for example, a specific on-call or operations group).
- Remember that role permissions determine which groups and contacts a user can send to. A contact visible to an org admin in preview can still be excluded from the final send if the sending role cannot access that contact’s group.
If different users see different preview counts for the same rule, this often indicates that their roles have different group access permissions.
Step 2: Confirm the rule’s selection criteria and contact membership
After confirming the sender’s role, verify that the rule really should include the missing contacts and that those contacts belong to accessible groups.
- Open the contact rule used by the notification or incident.
- Inspect the rule’s filters (for example, org unit code or other attributes) to confirm the conditions are expected for the missing contacts.
- Check the contact’s profile to make sure it meets the rule’s criteria and is a member of any group referenced by the template, or at least of a group that the sending role can access.
If a contact meets the rule’s conditions but is not in any group that the sending role can reach, the contact can appear in an admin’s preview yet still be excluded from the actual send.
Step 3: Fix group membership or role permissions and re-test
Once you identify a mismatch between rule logic, group membership, and role access, you can correct it and validate the results.
- Add the affected contact to a group that the sending role can access, or adjust the role’s permissions/templates so it can access the required group.
- Use the notification preview in the compose/send workflow again and confirm the contact now appears in the preview for the sending user.
- Send a test notification that uses only that rule and compare the final recipient count to the preview count.
After adding the contact to an accessible group, the contact will be included in the final message when the notification is sent.
Step 4: Validate rule behavior with a test notification
In some cases, a mismatch between preview and recipients comes from how the rule logic is applied when sending, especially with more complex filters or with “does not contain” operators.
- Open the rule and review all filter criteria, including any “does not contain” values or lists of values.
- Select Preview Contacts in the Rules UI and note the contact count.
- Create a dedicated test notification that selects only this rule as the recipient source.
- Compare the recipient count in the test notification to the preview count.
A previously fixed backend issue caused the query used in rule previews to differ from the query used when building the notification recipient list, especially when “does not contain” used multiple values, which could add unexpected contacts. That correction has been deployed; if you still see differences, re-check the rule filters for unintended values and keep in mind that role permissions can cause user-to-user variations.
Step 5: Troubleshoot incidents that omit previewed contacts
For incidents, contacts may appear in the incident’s Contact Preview but be omitted when you launch the incident if the send-step recipient query uses incorrect logic.
- Review the incident template’s send-step recipient query and any variables used to filter recipients (for example, multiple District values).
- Be aware that older behavior could apply only the first value in a list (such as only the first District) when filtering recipients, which excluded contacts that matched later values even though they appeared in preview.
- After the logic correction has been deployed, re-launch the incident and confirm that the actual recipients now match the Contact Preview list.
If the recipients still do not match preview after the fix, re-check your incident filter logic to make sure it reflects the intended audience.
Step 6: Address scheduled notifications using contact rules
For scheduled notifications that are delivered to fewer contacts than the contact-rule preview shows, the rule itself may need to be refreshed.
- Create a new contact rule with the same conditions as the original rule, so it resolves the same contacts.
- Save the new rule, then open the related notification template or schedule.
- Replace the old contact rule with the new rule so the schedule uses the refreshed rule when it runs.
- On the next scheduled run (or via a manual test), verify that the notification reaches the expected recipients based on preview.
If a recreated rule still produces a mismatch on a scheduled send, the behavior may require a product update to fully resolve.
Step 7: Use preview effectively before sending
Using preview at the point of send helps catch rule or permission issues before you send a live notification.
- In the compose/send workflow, use the notification preview feature to list the contacts that the selected rule pulls and to see the contact count.
- If the preview shows fewer contacts than you expect, typical causes are: the sending user’s role has limited access to some contact groups, or some contacts are not affiliated with the static groups assigned to that role.
- Resolve any role or group issues and run the preview again to confirm that the recipient list and counts are correct.
When to collect details for further investigation
If you have verified role access, group membership, rule logic, incident filters, and rule recreation for schedules, but contacts that appear in preview still do not receive notifications, it may indicate a deeper product issue.
- Collect the notification ID (or incident ID) and note the exact rule name and filters that were used.
- Capture delivery/log details and screenshots of both the Preview Contacts view and the final recipient list.
Having these details ready enables faster analysis and resolution if you need to request additional help.