Inbound email actions -- problem identifying as reply email

jMarshal
Mega Sage
Mega Sage

jMarshal_0-1699021782831.jpeg


Hello, fellow Devs!

I'm having an issue with inbound email -- where replies are being identified as new emails. I have a workflow which sends an email automatically from a RITM...and replies to that email are appropriately added to the RITM by the OOB Inbound Action called "Update Request Item".

I have a requirement to send a particular notification, when someone replies to that email specific email, but still update the RITM appropriately...so I created an event and registered it and set up a new notification based on the event. I then modified the OOB Inbound Action to add the event to the queue...as follows (updated code pasted below). Note that I added the new function "queueAssignees()" to build an array of recipients for the email, that I can pass to the notification via event parms. The array contains users assigned to the associated sctasks...and I got this code from the OOB "sc_req_item comment events" Business Rule.

gs.include('validators');

if (current.getTableName() == "sc_req_item" && current.canWrite()) {

    if (gs.hasRole("itil")) {
        if (email.body.assign != undefined)
            current.assigned_to = email.body.assign;

        if (email.body.priority != undefined && isNumeric(email.body.priority))
            current.priority = email.body.priority;
    }

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

    function queueAssignees() {
        var assigneeArr = [];
        var assignGroupArr = [];
        //Query for non-pending sc_task records
        var catTsk = new GlideRecord('sc_task');
        catTsk.addQuery('request_item', current.sys_id);
        catTsk.addQuery('state', '!=', -5);
        catTsk.query();
        if (!catTsk.hasNext()) {
            gs.addInfoMessage(gs.getMessage('Comment cannot be viewed by technicians until work begins on the Requested Item'));
            return;
        }
        while (catTsk.next()) {
            //notify task assignees
            if (!catTsk.assigned_to.nil())
                assigneeArr.push(catTsk.assigned_to.toString());
            else
                assignGroupArr.push(catTsk.assignment_group.toString());
            //Add Work notes watch list users
            assigneeArr.push(catTsk.work_notes_list.toString());
        }
    }

    gs.eventQueue('sc_req_item.email_reply_update', current, assigneeArr, assignGroupArr);

    current.update();
}


...but while testing, the Inbound Action is not triggering because it seems to be identifying the email replies (which are being added to the RITM still, by the OOB Inbound Action, in production) as NEW emails, instead of replies...

...and this is quite confusing. I can't see how modifying the OOB Inbound Action would cause this...I could see it failing to do what I am trying to do, and from there I can t/s and dev further...but in this instance, it's not even recognizing the email received as a reply - thus, skipping the Inbound Action because it is not applied to NEW emails.

I have my subprod instance configured with a test email account "sn.test@domain.com" and I am sending to a live account (not a separate "catch all" in the Email Properties) for this test and replying from the actual account which recieved the message, without altering the watermark.

Taking the same action in production yields positive results, as it identifies the inbound email as a reply, triggers the action and updates the RITM...but I also need it to fire this event with the array of recipients in the parm1 & 2 spots, for the notification.

See attached images for screenshots (PII redacted), which may help identify the source of this issue...and thanks in advance for any help! Also, if you have an alternate solution to the initial problem (instead of creating an event from the Inbound Action), I'm all ears!

1 REPLY 1

Tony Chatfield1
Kilo Patron

Hi, unfortunately your redacted partial-screenshot, does not allow for an evaluation of your email message, but this can occur for a number of reasons.
Why are Inbound emails with in-reply-to headers classified as NEW? - Support and Troubleshooting (se...

Reply email recognised as New and opens a new incident for each reply - Support and Troubleshooting ...