Some notifications are not correctly sent to end users
It is not unusual that you have to deal with the following issue: An end users tells you that he did not get a notification he normally should have received. When this happens you should first run the routine checks:
1) The same notification has been sent correctly to other users, but not to the user that is raising the issue.
2) Our user has a valid email address in the sys_user table.
3) Notification is not subscribable, subscription is not allowed in the instance, anything related to subscription is OK.
4) By putting true to “Force sending notification” flag, notification is still not sent.
If the issue still exists after checking these 4 points, the incident really becomes a failure incident and a deeper investigation is then needed. In my case, my findings were as follows:
a) a warning was written in the notification log:
Notification ‘Activity Generic Notification’ (a0e25f080f030a4013f0fc4ce1050e97) excluded recipients because user’s device contains an empty or invalid email address (see “cmn_notif_device.email_address”): ‘Joe Employee’ (847de762db671a004951bc16bf961923)
b) Effectively, in your cmn_notif_device table, you don’t have email address for that user.
c) You also find out that you have very few other users with the same behaviour.
Root cause is found: in the cmn_notif_device table you have an empty email address. In ServiceNow, there are OOTB Business rules that align the sys_user table with the cmn_notif_device table. In our case they were active and unmodified.
So, the question now is: How come?
You probably import your users using a scheduled import. You probably run your import without running Business Rules (following best practices) and thus table cmn_notif_device is not correctly aligned. Let’s have a look at it in detail:
- I) An import of users is made in your table sys_user. A good practice says that we should not run Business rules. That’s why in many cases, we uncheck the option.
II) Some of the users you’ve imported may not have any email address but are recipient of a notification. (example: Assigned to an incident)
III) when this is the case, A new record is created in tables cmn_notif_device and cmn_notif_message but your users will not receive notifications (normal behaviour: they don’t have emails)
- IV) later on: a new import of users update your users (and their emails addresses if new one are defined). Don’t forget you still don’t run Business rules. That’s why your sys_user table is correctly updated but this is not the case for the table cmn_notif_device You then have a table with a correct email address (sys_user) and another table that has not been correctly aligned (cmn_notif_device). Once we have found the explanation, the next step is:
How to solve this issue?
A scheduled job to align cmn_notif_device after your daily user imports. Let’s say scheduled 1h after your daily user imports. The script should be as follows:
Wrong ways to solve the issue
- You may want to run a background script to align both tables. This will fix the issue when executing the script but you may get both tables unsynchronized in the near future (and related incident)
You may define new business rules checking the alignment of cmn_notif_device and cmn_notif_message tables with the sys_user table. But I don’t recommend such solution as you may have to modify such implementation in future product upgrades.