Updating Incident through mail gets ignored by system?

AdamUMC
Giga Guru

Hi there,

We have a Business Rule, it's called "incident query" (out of the box ServiceNow thing).

We have shielded the notifications of one group from the rest, by extending the script of this Business Rule.

No one can see the notifications of this group, unless you are a member of this group, unless you are a Caller of the notification or unless you are included in the Watch List of the notification.

What is happening now is: for this group we import notifications from a mailbox. That works fine.

What is wrong is that when such a notification needs to be updated with an email that refers to it (string at the bottom of the email or INC number in the subject of the email), this is NOT processed. For all other groups this works fine and the addition (mail) is processed as Additional Comment in the notification.

In the log we constantly see the following notifications: "Unable to locate incident e6e99f5f9701d6542f..... for inbound email processing". This notification is repeated every time.

How can this problem be solved? What is the cause?

Thanks!

Adam

5 REPLIES 5

Mark Manders
Mega Patron

Emails are processed as the user (as impersonation). The before query BR you mention is checking if the user has access to the record or not. So if you have somehow (unclear how, please share the code) limited access to parts of the incident, it is very well possible that the incident can't be found.

Replacing your logic with deny-unless ACL (Xanadu) or Data Security (Yokohama) could resolve it. But it depends on what you are actually hiding and in what way.


Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark

Thanks @Mark Manders.

The users who try to update the Incident by mail, can see their (usually own) Incident through the Service Portal.
This is a part of the script "incident query" BR script:

//b.Non GROUPNAME1 users can only view GROUPNAME1 incidents as a caller or watchlist user
if (!gu.isMemberOf('GROUPNAME1')) {
current.addEncodedQuery("assignment_group!=4267f09287c5ddd0b2f7eb973cbb3520^ORcaller_id=" + u + "^ORwatch_listCONTAINS" + u);

}
//c. GROUPNAME1 users can only view GROUPNAME1 incidents and incidents as a caller or watchlist user
if (gu.isMemberOf('GROUPNAME1')) {
current.addEncodedQuery("assignment_group=4267f09287c5ddd0b2f7eb973cbb3520^ORcaller_id=" + u + "^ORwatch_listCONTAINS" + u);



Are you sure about this by the way? 

"Emails are processed as the user (as impersonation)."

Even flows are usually executed by "System User".

AdamUMC
Giga Guru

I have done some testing:

When I make myself member of GROUPNAME1 group and reply to an outbound ServiceNow Incident email, the mail is not processed; I get the same error.
When I'm Caller of the Incident; same problem.

When I disable this Business Rule for example, everything works well.
This: "Emails are processed as the user (as impersonation)." > seems to be correct; I'm mentioned as last updater of Incident.