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?

[sergiuhica]

Hello,

Below you can find the script:

var userId = gs.getUserID();

current.addQuery("opened_by", userId)

            .addOrCondition("opened_for", userId)

            .addOrCondition("watch_list", "CONTAINS", userId);

[Chad Hall]

I'm facing this issue as well. In our case we do not want to allow anyone extra to see the HR Case but we do want to allow their email replies to add a comment to the case. This is for those scenarios where someone related to a case forwards an email from the case to a colleague. That user then sends an email back to ServiceNow with their comments. However, this business rule prevents them from seeing the case so the inbound action cannot find the gliderecord to run the update on.

I tried to get around this by declaring a weird custom global variable in my inbound action, then including a check for that within the business rule so it doesn't even modify their query if that variable is defined. But it seems to be searching for the existing record before it runs any of the code in the inbound action. I'm looking for a way to force some code to run before the inbound action finds the existing record, or a better way to conditionally run the before query business rule. And bypassing it for all non-interactive sessions is not a good option as that opens up read access to every HR case if you just use a non-interactive session such as web services. That's a gaping wide back door we can't have.

Does anyone have another idea? Maybe a way to detect that its the email engine running the query? Something else entirely?

Thanks!

[jainb]

Hi,

Im facing the similar issue to avoid the BR for inbound actions, Did you find a way to handle this?

[Chad Hall]

I did actually find a workable solution to this using a global variable. Here's what I did:

• Updated the inbound action to define and then clear a global variable:

gs.include('validators');

try {
  // open up case access to allow the comment
  var g_open_hr_case_for_comments = true;

  if (current.getTableName() == "hr_case") {
    // process the comment update
    if (!current.active){
      gs.eventQueue("hr.casedclosed.reply", current, gs.getUserID());
      // lock the case access again
      g_open_hr_case_for_comments = false;
      event.state="stop_processing";
    }
    else
    {
      current.comments = "reply from: " + email.origemail + "\n\n" + email.body_text;
      current.update();
    }
  }
}
finally {
  // lock the case access again finally
  g_open_hr_case_for_comments = false;
}

• Updated the 'Restrict query' business rule condition to "gs.isInteractive()", so it only runs on interactive sessions
• Added ACLs to make sure the cases stay secured for non-interactive sessions but still allow comment updates when the global variable is set by the inbound action:
• • Read ACL on hr_case with script:

answer = (typeof g_open_hr_case_for_comments != "undefined" && g_open_hr_case_for_comments == true);

• • Write ACL on hr_case with script:

answer = (typeof g_open_hr_case_for_comments != "undefined" && g_open_hr_case_for_comments == true);

• • Read ACL on hr_case.comments with script:

answer = (typeof g_open_hr_case_for_comments != "undefined" && g_open_hr_case_for_comments == true);

• • Write ACL on hr_case.comments with script:

answer = (typeof g_open_hr_case_for_comments != "undefined" && g_open_hr_case_for_comments == true);

With these changes the inbound action, running as the user who sent the email, is able to find the existing HR case to update, the ACLs allow the comment update, and the UI and other non-interactive sessions maintain the proper security to otherwise keep users out of the cases completely.

Keep in mind, we are still on the non-scoped HR. After we upgrade to London we will be moving to scoped HR. So I imagine I'll need to totally reimplement this and everything else custom we've done in HR.

[jainb]

Hi,

I'm using the scoped application and instead of using ACL, we are using a custom before Query BR to restrict the cases from security point to all users.

Can I use global variable in BR itself along with gs.interactive() condition to check it escapes Before query BR or anything else needed.