This week I was working on a scoped app and discovered something about inbound (email) actions I thought worth sharing.
Summary: Allow other apps to update your scoped table(s) and check your ACLs carefully.
I created an inbound action so users could reply to email messages and automatically update the corresponding ServiceNow record. When I tried responding, the update never got back to the record so I checked the Received mailbox, opened the message with "Ignored" state and found this:
watermark's target table 'x_loaner_request' does not match any Inbound Action table, setting to 'Ignored' state
Unable to locate x_loaner_request 8790f368131912001098b5f12244b0df for inbound email processing
Unable to locate x_loaner_request 8790f368131912001098b5f12244b0df for inbound email processing
Unable to locate x_loaner_request 8790f368131912001098b5f12244b0df for inbound email processing
There are two different issues being presented here. The first line indicates that the scoped table is not allowing other scopes (including Global) to write to the table. Navigate to System Definition> Tables, locate and open your table record. Under the Application Access section, set the Accessible from field to All application scopes and check the fields "Can create" and "Can update".
The remaining lines are simple ACLs. I was under the impression that the system account was processing the inbound action and writing the results to the record. I later learned that inbound actions impersonate the sender (in this case my chuck.tomasi account) and I didn't have the right roles or security rules to write to the comments field on that record. After some basic ACL updates, those messages disappeared as well and I have my replies showing up in the comments field (and activity history) of my record.
Remember to allow other scopes to write to your table and double check your user's roles/security rules for the record (and fields). Even veterans need a reminder once in a while.
9 Comments
