Connect Chat and Worknote Notifications

[Callum Ridley1]

For some, like myself, worknotes in the system are more useful if they create notifications to ITIL users when tney are added. With this in mind, using Connect Chat can become problematic. Every time a chat message is added against a record in ServiceNow that has worknote notifications, an email is generated and sent. For lengthy chat sessions this can generate a large volume of unwanted email notifications.

To combat this we need to stop an email notification from being sent if the origin of the worknote is from a chat message. after a bit of digging around the base system tables I came up with the following script include that provides a way of determining the origin of a worknote or comment on a record.

Type: Script Include

Name: chatChecker

var chatChecker = Class.create();
chatChecker.prototype = {
         initialize: function() {
         },
         check: function (tableName, recSysID){
                   //first we check if there is even a conversation associated to this incident...
                   var liveGroupProf = new GlideRecord('live_group_profile');
                   liveGroupProf.addQuery('table', tableName);
                   liveGroupProf.addQuery('document', recSysID);
                   liveGroupProf.query();
                   if (!liveGroupProf.hasNext()) {
                             //no profile found; then just send as normal.
                             return true;
                   }else{
                             // Found a profile, now check to see if there is a new chat message associated with it
                             liveGroupProf.next();
                             var liveFeedMessage = new GlideRecord('live_message');
                             liveFeedMessage.addQuery('group',liveGroupProf.sys_id);
                             liveFeedMessage.orderByDesc('sys_created_on');
                             liveFeedMessage.query();
                             liveFeedMessage.next();
                             if(liveFeedMessage.chat_message == true){
                                       return false;
                             }else{
                                       return true;
                             }
                   }
         },
         type: 'chatChecker'
};

Then on the notifications you'd like to stop when the trigger is a chat message, you can add the following code into the "Advanced Condition" field.

var chatChecker = new chatChecker();
answer = chatChecker.check(current.getTableName(), current.sys_id);

I hope this helps someone else!

[piranavankidnap]

Hi,

First of all thanks for your script, I used your script but I have an issue and I need your help.

Step 1 : End user chat with the operator

Step 2 : Create the incident from the chat

Step 3 : End user add a comment on live feed (automatically created a comment on the form)

Step 3.5 : 0 notification => OK

Step 4 : Few hours later End user open the incident on the BO (back office) and add a comment

Step 4.5 : 0 notification => NOK

How can we found exactly if the comment was created by chat or by BO form when the fist comment was a chat comment.

Thanks in advance,

[Callum Ridley1]

I'm not sure why this wouldn't be working for you, it certainly works fine for me, unless ServiceNow have changed something in the background. I'll have a look next week when I'm back in the office and update then.

Could you please let me know which version of ServiceNow you are running.

[Callum Ridley1]

I I have tested this extensively and I cannot reproduce the issue. Please ensure that there are no other factors on your instances that are blocking notifications from being sent. The script I provided will always allow a message to be sent, unless the source of the update was from a chat window.

[GwenLG]

Thanks Callum for your Response.

After analysing, ChatChecker is really blocking notification sending as Piranavan said (log tests done).

The situation is this one :

A chat User opens a conversation with a chat Operator.

--> Live Messages are recorded in the specified table (live_message) in a 1 to 1 conversation

Operator Open an incident and save it

--> Live Profile is created

--> Previous Live Messages and future Live Messages are recorded in a conversation, renamed as INC Short description

Chat is still opened.

Operator add a comment in the incident

--> Comment is added in the incident

--> Comment is NOT added in the Live Feed

--> Live Message table is not updated with the comment (new record)

--> Chat Checker take the last live feed message. It's a chat --> Wrong message analysis

The Chat is now closed

Operator add a comment in the incident

--> Comment is added in the incident

--> Comment is NOT added in the Live Feed

--> Live Message table is not updated with the comment (new record)

--> Chat Checker take the last live feed message. It's a chat --> Wrong message analysis

We are facing these questions :

Is it normal to not have new entries in Live Message table during chat conversation when we add a comment on the incident ?

Is it normal the Live feed's not updated (I don't see, in this script, what could cause this behavior) ?

Is the ChatChecker comparing last message in the incident with the last chat message when the inc origin is Chat and isn't it a mistake in this case ?

How could we resolve these issues ?

Thanks in advance

Regards,
Gwendal.

[Callum Ridley1]

Hi Gwendal,

after another round of testing on a completely fresh OOB Developer instance I have come to the conclusion that my script is not blocking the notifications, however... the notifications are being blocked. All of the notifications you are expecting will probably be in "System Mailboxes > Outbound > Skipped"

I have verified that my script is not causing these notifications to be skipped by adding logging to the script, no logs are produced and therefore the script is not running at all. I've also tried notifications without the script in place at all, also results in no notifications.

I think you might be best raising an incident on HI for this as I expect there is something else going on in the background that is stopping the notifications from sending.

All of this was tested on a fresh instance of Jakarta.

Callum