Direct answer
A CRM notification passes through four links: something must trigger it, someone must be named as the recipient, a channel must carry it, and conditions must allow it at that moment. Check them in that order, because a break early in the chain makes the later links irrelevant. Use one controlled test record, not live customers, and note what you find at each link. This page describes structure, not any particular product's menus or current behaviour; your CRM's own documentation is the reference for where each setting lives. It does not promise that a notification will never be missed.
Link 1: did the trigger fire?
Look at whatever history your CRM keeps for automations or workflows. Did the rule run for the test record? If it never ran, the fault is in the trigger: a condition that is not met, a rule that is switched off, or a change in how records reach the CRM. If it ran but nothing was sent, move to the next link.
Link 2: was there a named recipient?
A notification with nobody to go to goes nowhere. Check who the rule sends to. Common gaps are a record with no owner assigned, an owner who has been deactivated, and a rule that sends to a team where nobody sees team alerts. Decide whether the recipient is a person or a team, and make sure the assignment rule always produces someone. The roles and permissions setup is often where this is settled.
Link 3: channel settings
A sent message can still not reach a person. Check on both sides:
- The recipient's own notification preferences for that type of event
- Whether the message reaches the device, such as mobile push settings
- Whether the mail system filters or hides messages from the CRM's sender address, and whether it should be allowed
- Whether the recipient looks at that channel at all during their work
Link 4: timing and branching conditions
Rules often contain conditions: only for some sources, only during certain hours, only if a field has a value. A notification may be correctly withheld by a condition nobody remembers writing. Read the rule's conditions against the test record and check whether a delay or batch setting makes an alert arrive later than people expect.
Integration users and permissions
If records or alerts pass through a connection, check the account that connection uses. If it lost access or lacks permission to see the record, the rule may not fire for it. This is a common cause when notifications stop after someone leaves or an account is changed. See API credentials and service account setup.
Alternatives and one owner per alert
Not every alert should be an email. Decide per alert whether a task, an email or a chat message fits the response you need, and give each alert one owner who is accountable for acting on it. A chat channel can suit team-wide awareness, as in Telegram lead notifications, while a task suits work that must be tracked to completion. Alerts that go to everyone are ignored by everyone.
A test-and-record routine
After any fix, create a test record, mark it clearly, watch each link, and write down what happened and when. Repeat after changes to users, fields, rules or the mail setup. A simple checklist of the four links with a date and the tester's name is enough. If you need a way to know when alerts stop, see automation monitoring and alerting.
Questions
Where do I start when nobody gets the alert?+
Start at the trigger: did the rule run for a test record? If it did not, nothing after it matters yet.
Why do notifications work for some people but not others?+
Usually because of the recipient link or the channel: a different owner assignment, personal notification preferences, or mail filtering on one side.
Can we guarantee a notification is always delivered?+
No system can promise that. Reduce the risk with a named recipient, a channel people watch, a test routine and a way to notice when alerts stop.
Should every alert be an email?+
No. Choose email, task or chat by the response you need, and give each alert one owner.
Where are the settings in my CRM?+
This page does not cover product-specific menus. Use your CRM's own documentation or its administrator.