|
I think, everything is said about email notifications and written down in uncounted articles. However, I was not able to find any good documentation on how exactly the final recipients list of a notification is built. At first, I thought that it couldn't be that difficult. But the deeper I got into the subject, the more complex it became. This article is the result of extensive research and testing, and I hope that the black box "recipients list" will become more transparent to you. |
|
Building the list of all recipients is a very extensive process, divided into the following five stages:
Basically there are two types of recipients: explicit recipients and subscribers and for both of them the respective lists are generated at that stage. The following two chapters explain how exactly this is done by ServiceNow.
(1.1) Collect all explicit recipients
Explicit recipients are individual users, complete user groups or even email addresses.
They can be gathered in two different ways.
Static recipients
Static recipients have been configured by the notification's creator in the "Who will receive" tab of the notification record, or are determined by any of the defined fields or groups:
Dynamic recipients
If "Send when" is of type "Event is fired" two additional checkboxes "Event parm 1 contains recipient" and "Event parm 2 contains recipient" will appear at tab "Who will receive":
When creating and queuing an event with :
gs.eventQueue("<event_name>", object, parm1, parm2);
you can store in parm1 and/or parm2
- a list of Sys_IDs from users or groups or
- just email addresses.
Additionally, there is also a checkbox "Send to event creator" which allows including the event creator to the recipients list.
(1.2) Collect all subscribers
In ServiceNow, a notification can be subscribable (see Documentation). That enables users to proactively subscribe to notifications which interest them and unsubscribe from notifications that are not mandatory (but not always, as you will see below).
Before users can manage their subscriptions (see Documentation) the respective field has to be set in the email notification record:
If checked, all active subscribers from table sys_notif_subscription will be read and added to the tentative list of users.
Notes:
- Groups cannot subscribe to notifications!
- Read the Documentation to understand how users can subscribe to notifications.
In this optional step, any existing user groups are dissolved and the group members and any group email addresses they contain are added to the corresponding lists.
In a baseline ServiceNow instance there are three fields in the form view of the table sys_user_group which are hidden by default, but for further understanding these fields should be made visible:
If a group is active, a specified group email address is always added to the list of email addresses, regardless of which users are extracted from the group!
The process for determining all group relating users is represented by the following diagram:
Users can delegate their responsibilities to other users for a period of time (see Documentation).
If activated by the system administrator, users can find at their personal profile page a related list "Delegates" and by clicking on "New" a new delegate record will be created.
After creation of a delegate record, the user will find in the form two fields which have impacts on extending the notifications' recipients list:
(1) Redirect all notifications - except meeting invitations - to the delegate.
(2) Redirect all meeting invitations to the delegate.
Notes:
- Delegates are only included if the checkbox "Exclude delegates" on the notification record is not ticked:
- This checkbox only appears on the form in case the "Send when" value is "Event is fired". But you also can change the value in the list view of all notifications.
At this stage, all users will be checked to decide whether they remain on the recipients list or not.
After checking a user is "active" or not, a lookup at table cmn_notif_device is performed. That table holds for all users their so-called devices through which they may receive any notifications. Usually, a "Primary Email Address" is automatically registered as a notification device when a user account with a valid email address is created.
Whether a user should receive a notification or not is then determined by a lookup at table cmn_notif_message:
- If there is no match, a corresponding record is created there and the user is added to the recipients list. That way, the user can restrict receiving further notifications by configuring his notification preferences (see Documentation).
- If there is a record, the configured conditions are validated (see Documentation), and the user is added to the recipients list if applicable.
Unfortunately, now it gets a bit more complicated because there are two hidden fields that can override the user-specific configurations and for a better understanding these two fields should be enabled:
Forcing a notification means that the relevant users receive the notification, even if they have not subscribed to the notification or have turned off the subscription. In addition, the users receive the notification even if the "Notification" field of the sys_user record is set to "Disable".
Basically both options are very similar and according to the Documentation the user should be able to unsubscribe when "Force delivery" is chosen. But during my extensive tests I couldn't see any difference. That means, whether you set "Mandatory" or "Force delivery" to "true", the recipient will receive the message in any case.
The following decision tree reflects the described filtering process and how is checked, whether a user is added to the final recipient list or not. This decision tree was not copied from any ServiceNow documentation, but is a result of many black box tests.
(5) Build final Recipients List
In the last step, the email addresses from the remaining users are merged with the possibly existing plain email addresses and any duplicates are removed.
For a better understanding of how the final recipient list has been created, use the "Preview Notification" feature of an opened notification record and hover with the mouse over the users:
