Force delivery of notification is not working. Why?Summary<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } There is a known issue with "force delivery" of notification in Washington DC and possibly earlier release versions. This issue seems to have been resolved from Xanadu or later versions. As per the product documentation for Washington DC version, "force delivery" of a notification should deliver a notification to the primary chosen device (mostly, email) of a user who have their notifications disabled. But this is not the case! In versions up to Washington DC, when a user has disabled "Allow notifications" but has left their "System notifications" enabled, then the "force delivery" enabled notification works. If a user has enabled "Allow notifications" but has left their "System notifications" disabled, then the "force delivery" enabled notification does not work. The above scenarios are for a user with their primary communication device being active (i.e. set to true). (referenced by: /cmn_notif_device_list.do page). NOTE: notifications with "force delivery" will reach only if it meets the above criteria. Notification preferences Individual user's per notification preference are persisted in sys_recipient_notif_preference table. If no user hasn't modified any notification preference in their login, then there will be no entry in that table. If they had, there will be an entry per notification with Send field reflecting whether it is true (enabled) or false (disabled). Allow notification is part of the sys_user.notification attribute. Suggested workaround If you are in an older version of ServiceNow, consider running a background script to obtain a list of users who have critical notifications turned off and re-enable them in a programmatic manner. You can also consider taking programmatic options such as when a user disables a notification and if an event is fired, watch out for the event and execute a background task that would either honour or dishonour their request to turn off a critical notification. For any assistance on these matters, you'd have to check the SN community portal as code customisation would be out of ServiceNow technical support scope.