Notifications: out of the box spam

Did you know that if a user unsubscribes from the notification “Change assigned to my group”, it will cause all his colleagues to be spammed?

This is caused by the way ServiceNow decides if an email is sent or ignored.

An email is considered a duplicate if and only if the recipients are the same.

Weight is also used to decide if a notification is sent or not.

I will show an example with some out of the box notifications for Change requests. But this will happen in any table with multiple notifications that have different weights.

The issue

When a user unsubscribes from the notification “Change Assigned to my group” but keeps the one for “New work notes” enabled, both notifications are inserted in the email table and both will be sent.

Assigned to my group → All group members except the user that unsubscribed

New work note → All group members

Example

We create a new itil group.

Group name: Notification Test

Group members: Abraham Lincoln, Bow Ruggeri, Carla Humble

All notifications enabled

We update an existing change and assign it to this group.

All members of this group have all the notifications enabled.

In this case, the expected result and the actual result are the same.

Two emails are generated with the same recipients and only the one with the highest weight is sent.

Change assigned to my group → Sent to Abraham Lincoln, Bow Ruggeri, Carla Humble

New worknote → Ignored

A member of the group disables one notification

Abraham Lincoln disables the notification “Change assigned to my group”, but maintains the one for the work notes active.

We update a change again and assign it to the same group.

The expected result and the actual result are no longer the same.

Two emails are generated with different recipients and both are sent.

Change assigned to my group → Sent to Bow Ruggeri and Carla Humble

New worknote → Sent to Abraham Lincoln, Bow Ruggeri and Carla Humble

Notice that Bow Ruggeri and Carla Humble didn’t do anything.

The action of their colleague had the side-effect of spamming them.

Workaround

A way of fixing this is to apply some changes to the “Ignore duplicates” business rule in the Email table.

  1. In the sys_email GlideRecord
  • Remove/comment the condition to check “recipients”
  1. Inside the loop
  • Perform a diff between the current record and the duplicate.
  • Each recipient will only be included in one of the triggered emails.

We repeat the previous test, and these are the results:

Change assigned to my group → Sent to Bow Ruggeri and Carla Humble

New work note → Sent to Abraham Lincoln