Skipping Inbound Action a suitable GlideRecord not found

[Katie A]

I have a custom table called Loaner Request which is extended from Task.

I created a basic notification on Insert on the Loaner Request table. We want the customer to be able to reply to that notification, which will update the Additional Comments field exactly the same as when they reply to an incident or other task. The notification does have the record number in the subject line AND the watermark in the email body.

I have a very simple Inbound Email Action called "Update Loaner Request".   current.comments = email.body_text;

However this is not working, the inbound action is skipped and the linked record is unable to be found.

These errors are appearing in the System Mailbox log.

Skipping 'Update Loaner Request', a suitable GlideRecord not found

Unable to locate loaner_request dd1b91214f79020040c601b28110c720 for inbound email processing

Anyone have any suggestions on how to fix?

[BenPhillipsSNC]

Thank you. This was the correct answer for my issue like this. I Impersonated the user I was sending emails as, and realized I had no access to the table. Granted them to an admin group and reprocessed the emails, and it worked.

[oleksiykosenkov · Accepted solution]

Generally it's about the user which gets impersonated during e-mail processing (it's not system or superuser) is missing access to subject record. Whatever reason it is, ACL or before-query Business Rule.

[Sumit Oberoi1]

How to resolve this, I have similar issue , with change and incident table, basically I have two accounts with same email id, but it picks the same account on every reply and return error.

Unable to locate change_request for inbound email processing and 

Skipping 'Name_Of_Inbound_Action', a suitable GlideRecord not found

and its working for few user that also have 2 accounts. Even I have the higher access.

[Tadz]

Hi Antony, How can we resolve this if it is a domain related issue?

Thanks,

Tadz

[antonymirza]

Hello Cris,

As I mentioned there are two ways to address it. Either we elevate the user's domain or else we apply some changes in existing process. For example, I noticed a scenario where an Incident was created for Caller A. Incident is on upper domain and Caller A belongs to lower domain which is whenever Caller A replies an email received from that incident his reply emails were not being processed and end up with this error e.g. "Unable to locate user for inbound email processing".

Ultimately, Caller A cannot even see the incident raised for him, I call it a poor implementation. Therefore, either elevate the domain of that user or apply some changes in process by managing a lower level task under that incident wherein Caller A has a visibility.

Brgds, AM