email processing

[joedumond]

What's the proper protocol for handling email replies to the instance?

When an incident is created, an email is sent.

When an incident is commented or worknoted, an email is sent.

I am seeing issues when someone replies to the incident notification.

It appears to happen when the Replier adds people to the To: or CC: line of the reply.

I can't quite narrow it down, and can't find the default email handling protocol for incident replies.

My best practice tells me that the Replier should leave the email alone and the body of the message becomes the comments.

If they want to add people that should be done through the watchlist of the incident.

[Travers M]

Would you be comfortable sharing your script code that looks at the incident and if it's closed it opens a new incident?   I mean, that is if that's what it actually does.   That would be handy to have.

[TrevorK]

Sure - not a problem.The first "if" (incident_state == 7) is when the Incident is "Closed" and the Else if when it is anything but "Closed".

If you need me to clean it up to make it more generic let me know. I removed many of our customizations that deal with business needs to make it a little more generic. This will make it a lot easier to understand. Any questions at all let me know.

I apologize if it's not easy to read, we haven't gone in an cleaned up the formatting of it in awhile.

(this is a "reply" rule on the Incident table)

gs.include('validators');





if (current.getTableName() == "incident") {





       if (current.incident_state == 7) {





               //create an incident from here

               var gr = new GlideRecord('incident');

               gr.initialize();

               //gr.u_new_call = current.u_new_call;

               gr.caller_id = current.caller_id;

               gr.category = current.category;

               gr.contact_type = 'Email';

               gr.u_caller_email = email.origemail;



               gr.short_description = "Reopened: " + email.subject;

               gr.description = email.body_text.replace('Ref:', 'Old Reference Id: ');

               gr.incident_state = 1;



   // TK Start - 09/18/2014

   // In relation to INC0116186

   //gr.insert(); -> I commented this out



   // Get the sysid of the record we inserted

   var incsysid = gr.insert();



   // We have the UID as an identifier, but not the sys id so we need to look it up

   var new_email = new GlideRecord('sys_email');

   new_email.addQuery('uid',email.uid);

   // In case there are multiple ones, we will grab the latest one which is this one. UID is not unique.

   new_email.orderByDesc('sys_created_on');

   new_email.query();



   if (new_email.next()) {

   GlideSysAttachment.copy('sys_email', new_email.sys_id, 'incident', incsysid);

   //ST - Changing the owner incident of the email that just came in.

   new_email.target_table = 'incident';

                 new_email.instance = incsysid;

                 new_email.insert();

   //End ST

   }



   // TK END - 09/18/2014

       }

       else {

               if (current.incident_state == 6) {

                       //Reopen the ticket and put it back to the round robin queue

                       current.incident_state = 1;

                       current.assigned_to = "";

                       current.close_code = "";

                       current.close_notes = "";

               }





               var UsrLookup = new GlideRecord('sys_user');

               UsrLookup.addQuery('email', email.origemail);

               UsrLookup.query();





               if (UsrLookup.next()) {

                       current.comments = "reply from: " + UsrLookup.name + " \n\n" + email.origemail + " \n\n" + email.body_text;

               }

               else {

                       current.comments = "reply from: " + email.origemail + " \n\n" + email.origemail + " \n\n" + email.body_text;

               }





               current.update();

       }

}

[Travers M]

Thank you so much for this, I look forward with trying to get this into ours.     It could eliminate the manual process we have now of creating a new incident manually and asking them to never do that again with nothing from actually stopping them from inevitably doing that again...

[TrevorK]

Once you put it in, if you have any questions at all feel free to message me. We tried to encompass everything in ours because you will find little things users want: attachments copied over to the Incident, the email itself copied over to the Incident (in the nice Outlook-style formatting in the Activities section), etc. All stuff that makes sense, but all stuff you may not find in examples within other Inbound Actions.

[Travers M]

I've been toying with ways to get it to cut off all of the stuff after the actual reply but haven't had much luck.   When you start getting into the longer chains of back and forth it just makes the activity all cluttered and you find yourself searching for the relevant content.