Inbound Action - Unable to locate "table" "sys_id" for inbound email processing

[FrancescoB61415]

Hello Everyone, 
I currently have an inbound action configured that should write email body to comments + attachment directly within the case.

(function runAction( /*GlideRecord*/ current, /*GlideRecord*/ event, /*EmailWrapper*/ email, /*ScopedEmailLogger*/ logger, /*EmailClassifier*/ classifier) {

    if (email.user_id.sys_class_name == 'csm_consumer_user' && current.state != 3) { 

        current.comments = email.body_text;
        current.update();

        var gsa = new GlideSysAttachment();
        gsa.copy('sys_email', email.sys_id, current.getTableName(), current.sys_id);
    }

})(current, event, email, logger, classifier);

The email is sent by a user listed in the csm_consumer_user table (sys_class_name -> csm_consumer_user), and the consumer is tracked in the case through a custom field.

The user has all the necessary permissions/role to access the case table and perform operations on comments. However, despite this, when the system processes the email, I encounter an error, as shown below:

(User ID is populated)

I have also verified the sys_watermark, and all sent emails correctly include the source record.

[Naveen20 · Accepted solution]

The error is misleading — the record exists, but the inbound processor impersonates the sender (email.user_id) when locating the target, and the consumer user fails the read evaluation, so it reports "Unable to locate." Your script never runs because the target lookup fails before the action is invoked.

For sn_customerservice_case, OOB read access for consumer users is granted through the standard relationship (the consumer field, plus account/contact linkage) and the query business rules that filter cases for external users. Linking only via a custom field bypasses all of that, so the consumer cannot read their own case.

Two options:

1. Populate the OOB consumer field on the case (in addition to your custom field) so the standard ACLs and query BRs grant read access.

2. Add a read ACL / extend the case query business rule on sn_customerservice_case to also match your custom field for sn_customerservice_consumer users.

Quick verify: impersonate the consumer and open the case URL directly — if they get "Record not found," that confirms the ACL/query-BR path.