Inbound Email Action

[tulasi8]

Hi Community,

This was the inbound email action written in servicenow for ritm creation:

if(email.to.toLowerCase().indexOf("oracle.hris.cloudsupport@ajg.com")>= 0 || email.to.toLowerCase().indexOf("oracle.hris.projectsupport@ajg.com")>= 0 || email.to.toLowerCase().indexOf("oracle.hris.integrationsupport@ajg.com")>= 0 || email.from.toLowerCase().indexOf("no-reply@oracle.com")>= 0 && email.subject.toLowerCase().indexOf("unplanned outage - resolved for arthur j gallagher and co: hcm1574571822583 production, cloud account ehzo")>= 0 || email.from.toLowerCase().indexOf("no-reply@oracle.com")>= 0 && email.subject.toLowerCase().indexOf("announcement: unplanned outage extended for arthur j gallagher and co: hcm1574571822583 production, cloud account ehzo")>= 0){

var user = new GlideRecord('sys_user');

user.addQuery('sys_domain',gs.getProperty('AJGDomainSysID')); //AJG Domain ID

var mail = user.addQuery('email',email.origemail);

user.query();

if(user.next()){

//gs.log('Forward Inbound triggered'+user.getRowCount());

var cartId = GlideGuid.generate(null);

var cart = new Cart(cartId);

var item = cart.addItem('f8a02a8cdb776b04a8a37dfdae9619b9');// Oracle Cloud Support Operations

var pri= 3;

// Fill Out the Cart Variable Values

var grpName =gs.getProperty('AJGHRcloudsupportID'); // Sys_id of myHR Support

var grpName2 =gs.getProperty('AJGHRcloudprojectID');

var grpName4 =gs.getProperty('AJGHRISCCI');

var grpName5 =gs.getProperty('AJGUnplannedOracle');

if(email.to.toLowerCase().indexOf("oracle.hris.cloudsupport@ajg.com")>= 0)

{

cart.setVariable(item, 'v_assignment_group', grpName);

cart.setVariable(item, 'v_assignment_group2', 'Oracle Cloud Operations Support' );

cart.setVariable(item, 'v_area', 'Oracle Cloud Operations Support');

cart.setVariable(item, 'v_requested_by', gs.getUserID());

cart.setVariable(item, 'v_short_description', email.subject);

cart.setVariable(item, 'v_description', email.body_text);

cart.setVariable(item, 'v_watch_list', email.copied);

cart.setVariable(item, 'v_legislation', 'United States');

}

// On RITM Table

var ritmSysID = "";

var ritmRec = new GlideRecord("sc_req_item");

ritmRec.addQuery("request", rc.sys_id);

ritmRec.query();

if(ritmRec.next())

{

// gs.log('ritmRec:' +ritmRec.number);

ritmSysID = ritmRec.sys_id;

ritmRec.u_location = loc;

}

}

One of the user sent mail to "oracle hris cloud support" for ritm creation through inbound email action  :

Mail triggered to the group , but the ritm was not created . So i checked in email logs, from there its showing logs like "Skipping script 'RITM Creation -AJG', email is type 'reply', which does not match Inbound Email Action's type 'new'".

How can ServiceNow is considering this email as reply instead of new . Can anyone please help on this. @Ankur Bawiskar 

Regards,

Tulasi.

[Vikram Reddy]

Hi @tulasi8,

This is actually a well documented quirk of how the platform decides email.type before any Inbound Email Action even runs. ServiceNow checks three things in order on the inbound sys_email record: first a watermark match (the hidden "Ref:MSG..." string appended to outbound notifications), then the In-Reply-To/References headers against a previously sent Message-ID, and only if both of those come up empty does it fall back to scanning the subject and body text for a literal record number pattern (INC0010007, RITM0010398902, and so on) that exists in the system. If that bare number turns up anywhere in the text, the message gets stamped type reply, full stop, regardless of whether the subject carries RE:/FWD: and regardless of whether the record it matched is Closed.

That is exactly what's happening in your screenshot. The body reads "Reopening this ticket with full context (please reference closed ticket) RITM10398902", plain text, no threading, no In-Reply-To header pointing back to anything. But that literal RITM number is enough to flip email.type to reply, and your action "RITM Creation -AJG" is scoped to type new, so it gets skipped with exactly the log line you posted.

A few things worth checking or doing:

• sys_email record: open the logged email and check the Watermark field. If it is blank, you have confirmed this is the body-text match path, not a genuinely threaded reply.
• Type field: on sysevent_email_action the Type choice is single-select (None, New, Reply, Forward, Forward Unknown), there is no multi-value option, so you cannot just add reply alongside new on the same action.
• Companion action: clone this action with Type set to None (or Reply) and, inside the script, branch on email.type explicitly, only running the cart/RITM creation logic when the record that was matched is actually Closed or Resolved, so you do not accidentally reopen or duplicate against a genuinely active ticket.
• Sender-side: since any bare record number in the body triggers this, ask requesters to avoid pasting old ticket numbers as plain text when kicking off a brand new request, or have them reference it as an attachment instead of inline text.

Worth noting: KB0622994 covers a related but distinct known issue, a watermark persisting when someone clicks Reply and edits the message, so if you see that pattern elsewhere it needs a different fix than this one.

Thank you,
Vikram Karety
Octigo Solutions INC

[Ankur Bawiskar]

@tulasi8 

the inbound action is of what type? New or Reply?

Are you sure the email which came doesn't contain any watermark?

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Tanushree Maiti]

Hi @tulasi8 

Refer KB: KB0535515 Inbound Email Action Type is not Matched 

Resolution

Troubleshooting

1. Open the email record.
2. Right-click the form header to change the view to Inbox.
3. Review the related log entries. These identify a reason an Inbound Action was skipped. 

Troubleshooting Reply Inbound Actions

As shown in the article in the overview, an email is classified as a reply only if it matches multiple criteria. If your inbound action of type Reply is not matching on an email you expect it to, it is possible your ServiceNow instance has actually classifiied the email as New or Forward because other Reply conditions do not exist in the email. To diagnose, check the following:

1. Open the email record in the Inbox view and review the log entries.
2. Check that the email subject's reply prefix is one of those listed in the glide property, glide.email.reply_subject_prefix.
3. If the email has a watermark (for example, Ref:MSG000001), check that it exists and refers to a record that exists in the same table as your Inbound Action's target table.
4. If the email has a record number in the subject, check that it exists and is in the same table as your Inbound Action's target table.