Prevent "duplicate" outbound email notifications (Comment / Work_notes)

[kjcv912]

We have HR Case Email Notifications for both:

*Comments

*Work_notes

Sometimes the desk agent update one field, SAVE and update next field + hit the SAVE button, 2 emails will be sent.

The Business Rule "Ignore duplicates" seem not to prevent this type of "duplicate".

Business has requested me to prevent duplicate outbound notifications and so far have I briefly looked into using javascript in the notification checking for same email in Mailbox-Outbound-Outbox within a short timeframe (mark duplicate as "skipped")

Are there even more options/ideas how to prevent duplicate emails to be sent?

/Stefan

[Brian Dailey1]

Hi Stefan,

I agree with Brad et al about it being a training issue, if the updates are each different then selectively sending them would require a lot of code/logic behind it.

That being said, I've modified our BR "Ignore Duplicates" on [sys_email] to take into account those messages that are weighted=0, as we would get truly duplicate notices sent out when these would fire (e.g., Incident Closed/Resolved) along with another less important message with the same content (e.g., "Incident Commented").

Here is the modified function from our Business Rule:

removeDuplicateEmails();

function removeDuplicateEmails() {

      var myWeight = current.weight;

      var myInstance = current.instance;

      var mySubject = current.subject;

      var myBody = current.body;

      var myRecipients = current.recipients;

      // Search for any pending email with the same recipients from the same ticket

      var duplicate = new GlideRecord('sys_email');

      duplicate.addQuery('instance', myInstance);

      duplicate.addQuery('recipients', myRecipients);

      duplicate.addQuery('type', 'send-ready');

      // include a sys_created_on query from 1 hour before now and 1 hour after now to limit the extensions we include in the query

      var s = new GlideDateTime();

      s.subtract(3600 * 1000);

      var e = new GlideDateTime();

      e.add(3600 * 1000);

      duplicate.addQuery('sys_created_on', '>=', s);

      duplicate.addQuery('sys_created_on', '<=', e);

      duplicate.query();

      if(myWeight == 0){

              while(duplicate.next()) {

              // If not of weight=0 (always-send)...ignore this duplicate

                      if (duplicate.weight != 0) {

                              duplicate.type = 'send-ignored';

                              duplicate.update();

                              //gs.log("BR-Ignore duplicates - MSB, duplicate ignored (" + duplicate.subject + ")");                            

                      }

              }

      }

      else{   // myWeight > 0        

              while (duplicate.next()) {

                      // If myWeight is greater or same, or the subject and body are same...ignore this duplicate

                      if ((duplicate.weight == 0) || (duplicate.weight >= myWeight) || ((duplicate.subject == mySubject) && (duplicate.body == myBody))) {    

                              // Ignore me

                              current.type = 'send-ignored';

                              //gs.log("BR-Ignore duplicates - MSB, self ignored (" + current.subject + ")");

                      }

                      else {

                              duplicate.type = 'send-ignored';

                              duplicate.update();

                              //gs.log("BR-Ignore duplicates - MSB, duplicate ignored (" + duplicate.subject + ")");                            

                      }

              }

      }

}

Hopefully some others can use this as well.  

-Brian

[kjcv912]

Thanks Brian

I will print your script on paper to understand it better, will review it statement by statement and comparing it with the OOB version.

I would say that our SN implementation is sending too many emails, even I am suffering of the flood of emails and I do as many others do, create Outlook client rules.

The ideal solution would be to prevent SN to send them, the 2 last duplicates I got were from the DEFECT management module.

Changing the OOB BR so it also handle weight 0 is a very good idea that would reduce the flood of emails for us.

/Stefan

[kjcv912]

Today did we deploy 5 Email Notifications; 3 with weight 100 and 2 with weight 50.
The goal is to avoid duplicates being sent by the same notification script within a short time frame and

the second goal is to drop email when another more important is sent by another notification script (different weight values is used for the second goal).

Will be interesting to monitor if it will reduce the flood of emails to some extent:-)

[Brian Dailey1]

Yes.   Basically, the OOB version of this business rule does not take into account notifications with weight=0 when checking for others as duplicates.  

i.e., the system will always send the notice with weight=0, but it wouldn't compare this message to others with a different weight (e.g., weight=50) to see if they might be duplicates.

That said, my BR above compares ALL matching notices without exclusion, but still will send every message that has weight=0...

Thanks,

-Brian

[stevesmith]

According to the Wiki, "0" will cause the notification to always send. Try a weight of "1."

https://wiki.servicenow.com/index.php?title=Email_Notifications#Creating_Email_Notifications