Inbound Email Action does not work without a user with roles.

AB6
Tera Contributor

Hi Community!

We have created an inbound email action in [facilities_request] table so end users could reply to email messages and automatically resolve the facilities request record. The problem here is when we try to reply with a user that has no roles, the update never processed and the record is not updated. I checked the Received mailbox and the message has the "received" state, but the “target” field  is empty with this error string:

 

“Unable to locate facilities_request beacb4eadb002b00d3a103c3ca961912 for inbound email processing”

 

This case just happens with users that have no roles. We need this response to be processed by any user, despite the roles it has associated.

Thanks.

1 ACCEPTED SOLUTION

Mark Stanger
Giga Sage

The problem is probably that the user cannot read the record so they can't access it.  The user needs to be listed in the 'Caller', 'Opened by', 'Opened for', or 'Watch list' fields to be able to read Facilities request records.  They can also access the record with one of the facilities roles.  This is controlled by the 'Update user query' business rule on that table and a couple of read ACLs.

The easy way to verify when you will receive this error is to impersonate the user in question and then try to access the facilities table.  If they don't see the record there then they won't be able to update the record in inbound email.

 

View solution in original post

2 REPLIES 2

Michael Fry1
Kilo Patron

In the inbound action, is there a role limiting who can trigger it? if yes, try removing the role(s):

find_real_file.png

Mark Stanger
Giga Sage

The problem is probably that the user cannot read the record so they can't access it.  The user needs to be listed in the 'Caller', 'Opened by', 'Opened for', or 'Watch list' fields to be able to read Facilities request records.  They can also access the record with one of the facilities roles.  This is controlled by the 'Update user query' business rule on that table and a couple of read ACLs.

The easy way to verify when you will receive this error is to impersonate the user in question and then try to access the facilities table.  If they don't see the record there then they won't be able to update the record in inbound email.