Is there a way to prevent duplicate notifications from going out when a comment is attached from an inbound email?

andrewcrawford
Kilo Contributor

Currently, by default, we send out notifications for every comment added to the incident form. However, we run into an issue when we email a client directly, and have the body of that email attached to the incident as a comment. This leads to the client immediately getting a notification with the same information they just received from the original email.

Since we need to make sure that comments added directly to the incident form are still sending out email notifications, we need to design something that will recognize when a comment is added from an inbound email, and know not to send out a notification. I originally tried designing a notification rule that overrides the existing comment notification, but I could not figure out which event to put in the "when to send" conditions that would lead to this rule working correctly. ServiceNow HI informed me that there was no way to accomplish this out-of-the-box, and that it could possibly be custom scripted, but I don't know how to go about doing that either.

1 ACCEPTED SOLUTION

Hi Andrew,



Can you explain "When we email them directly?" Are you talking about directly from Outlook (or some other mail client app) outside of ServiceNow?



If that's the case an the mail goes back to ServiceNow (and the user), ServiceNow updates the incident, triggers a notification with the same comments, and the user gets that one. Let me know if I'm close to hitting the dart board on this one.



If that's the case, this is a process issue more than a technology issue. The answer is, stop replying to messages from Outlook. ServiceNow doesn't have way to determine if the incident was updated from an email or from a browser. It just knows "Someone made comments, send an email."


View solution in original post

14 REPLIES 14

The issue I have is that I didn't consider that the IT Tech would comment upon assigning themselves so they both fire at the same time.



That makes me think the Send to event creator checkbox is checked. Uncheck it and the person making the change won't get it, but if they assign it to someone else.


Sorry I'm sort of new to the community so I hope I'm not hi-jacking rather than adding helpful input/scenarios.



The issue is not who is getting them in this case.   It's that both notifications are being triggered and I can't find another condition that will work.



The ITIL user is reviewing the incident and deciding whether or not to send out a notification.   If yes, they are supposed to send out the initial outage notification letting stake holders know about it.   Then, when they comment, the next one is supposed to go out as an update.   What's happening is, the tech is saying yes, send the notification, and commenting at the same time (which is normal behavior), but it's triggering both.




This is the 2nd Notification   to be sent upon assigned to being set and "notify Management" is set to true.




Acknowledged.PNG



This is the 3rd notification to be sent when Additional Comments changes (ONLY on update)


Additional Comments.PNG





As I type, I just got one where they ITIL User Got the initial notification internally to let them know there is an incident, they went on, assigned themselves, made comments and closed.   I got closed first, then Updated, then acknowledged



Do you think I should call support or professional services?  


Hi Carl,



No issue with the 'hijacking'. The more input we get, the better the response. You can start with support. If it gets too deep, they may refer you to professional services (sort of like your regular doctor sending you to a specialist.)


Thanks for the reply Chuck.



I tried adjusting the weight of the notification rules, but that did not solve the issue. I suspect the reason why is that one notification rule is looking at the Inbound Actions Table to reference the "email.read" event, while the rule I want to suppress is looking at the incident table's incident.commented event. I've also been trying to find a way to get the rule looking at "incident.commented" to identify when the comment is coming from an email, but I can't find any way to do it that actually works.


Ah, that explains the double email (being on two different tables.)



As for detecting whether it came from email vs. adding comments in the comments field, remind me again why that matters.