Prevent ServiceNow sends emails to non-existence email users

georgechen
Kilo Guru

Hi folks

I have been trying to find a way to prevent ServiceNow sending emails (notifications) to non-existence email users.     One solution in my head is to set the

sys_user.notification to 1 (none) so the users have a notification device deactivated.     Update associated email business rules and script includes together to achieve this.

I am however wondering if any OOTB design that can help in this issue so there is no need to amend any rules or scripts.  

The deactivation of sys_user.notification seems to be feasible, but I wonder if any comments that could utilise fully the OOTB features in the Fuji release.

Reference: Subscribable, mandatory and force delivery options on Notifications

Regards,

1 ACCEPTED SOLUTION

Dub Myers
ServiceNow Employee
ServiceNow Employee

Email Filters are applicable only to inbound email.



What is a "nonexistent email user" in your system?   And what logic is used to determine this?   Is it -


1. a valid user with an invalid email address?


2. a user who is inactive now (perhaps left the company?)


3. an automation user account, not a human, that is active in the system, but should not receive emails?


4. something else?



Options


Notification Filters


Using notification filters like "unsubscribe" on a user's subscription/preferences will prevent a notification from going out to the device associated with that notification.   If another device gets created for that user and associated with the notification, you would also have to 'unsubscribe' on that one as well.



User Record - Disable Notifications


Your original suggestion to disable notifications at the user record is as OOTB as it gets.   Since ServiceNow has no functionality that knows how to pick which users you define as "nonexistent", you would need to implement the code to set this flag.



User Record - Deactivate User record


Depending on what 'nonexistent email user' means, you can also consider simply deactivating the user entirely.   This impacts broader functionality than just notifications, and is most closely associated with #2 meaning above.


View solution in original post

7 REPLIES 7

Thanks Alexander for that.   I have actually activated it already, but some say it only works for incoming, is this true?


Dub Myers
ServiceNow Employee
ServiceNow Employee

Email Filters are applicable only to inbound email.



What is a "nonexistent email user" in your system?   And what logic is used to determine this?   Is it -


1. a valid user with an invalid email address?


2. a user who is inactive now (perhaps left the company?)


3. an automation user account, not a human, that is active in the system, but should not receive emails?


4. something else?



Options


Notification Filters


Using notification filters like "unsubscribe" on a user's subscription/preferences will prevent a notification from going out to the device associated with that notification.   If another device gets created for that user and associated with the notification, you would also have to 'unsubscribe' on that one as well.



User Record - Disable Notifications


Your original suggestion to disable notifications at the user record is as OOTB as it gets.   Since ServiceNow has no functionality that knows how to pick which users you define as "nonexistent", you would need to implement the code to set this flag.



User Record - Deactivate User record


Depending on what 'nonexistent email user' means, you can also consider simply deactivating the user entirely.   This impacts broader functionality than just notifications, and is most closely associated with #2 meaning above.


Hi d-mile



In response to the questions



What is a "nonexistent email user" in your system?   And what logic is used to determine this?   Is it -


1. a valid user with an invalid email address?     If a user email address contains noaddress or duplicate, we consider it as invalid



2. a user who is inactive now (perhaps left the company?) (disregarding the account status, it would still be an valid address as long as it meets 1.



3. an automation user account, not a human, that is active in the system, but should not receive emails?   Yes and No there are exceptions on accounts that carries out certain routine/system tasks



4. something else?   Well actually we also have a custom field named email status which differentiate email address as 'Valid Email', 'Invalid Email', and 'Do not send'.   this field is maintained by SD Users and also Inbound Action script that receives undeliverable from remote post masters.



Hopefully this helps



Regards,