Request Item Workflow Not Starting when using Cart API and Email Inbound Action for Guest user

[Shawn Dowler]

I am using the following script on an inbound email action. It works as expected when the email address is matched to an existing user, but for guest users it creates the REQ and RITM, but the RITM workflow doesn't start until the RITM is saved from the form. Then the workflow on the RITM kicks off and creates the first task.

var cart = new Cart();
cart.requested_for = gs.getUserID();
var item = cart.addItem('724f863d13e95640bc4830782244b002');
var details =   'Sender: ' + email.origemail + '\n\n';
   details += 'To: ' + email.direct + '\n\n';
if (email.copied) {
   details += 'CC: ' + email.copied + '\n\n';
}
   details += 'Subject: ' + email.subject + '\n\n';
   details += 'Body:\\n' + email.body_text;
cart.setVariable(item, 'v_details', details);
var cartmsg = "received from: " + email.origemail + "\n\n" + email.body_text;
var rc = cart.placeOrder();
// Add attachments to RITM
var ritmSysID = "";
var ritmRec = new GlideRecord("sc_req_item");
ritmRec.addQuery("request", rc.sys_id);
ritmRec.query();
if(ritmRec.next()){
   ritmSysID = ritmRec.sys_id;
}
var emailRec = new GlideRecord("sys_email");
emailRec.addQuery("uid", email.uid);
emailRec.orderByDesc("sys_created_on");
emailRec.query();
if(emailRec.next()){
   GlideSysAttachment.copy("sys_email", emailRec.sys_id, "sc_req_item", ritmRec.sys_id);
}

I get the following errors in the log if they might help pinpoint the issue:

org.mozilla.javascript.EcmaError: Cannot convert null to an object.
Caused by error in <refname> at line -1
org.mozilla.javascript.EcmaError: Cannot convert null to an object.
Caused by error in <refname> at line 1
==> 1: sc_req_item_stageGetChoices()
org.mozilla.javascript.EcmaError: Cannot convert null to an object.
Caused by error in <refname> at line 1
==> 1: sc_req_item_stageGetChoices()
org.mozilla.javascript.EcmaError: Cannot convert null to an object.
Caused by error in <refname> at line -1
org.mozilla.javascript.EcmaError: Cannot convert null to an object.
Caused by error in Business Rule: 'sc_req_item_stageGetChoices' at line 41
38: else {
39: // We have not started a workflow for the item yet (pending request
40: // approval) so determine the version we will eventually be using
==> 41: version = new Workflow().getVersion(current.cat_item.workflow).sys_id + '';
42: }
43: wfs.setWorkflowVersion(version, current.context + '');
44: wfs.getChoices(current.stage, answer);
org.mozilla.javascript.EcmaError: Cannot convert null to an object.
Caused by error in <refname> at line 1
==> 1: sc_req_item_stageGetChoices()
org.mozilla.javascript.EcmaError: Cannot convert null to an object.
Caused by error in <refname> at line -1
org.mozilla.javascript.EcmaError: Cannot convert null to an object.
Caused by error in <refname> at line -1
org.mozilla.javascript.EcmaError: Cannot convert null to an object.
Caused by error in Business Rule: 'sc_req_item_stageGetChoices' at line 41
38: else {
39: // We have not started a workflow for the item yet (pending request
40: // approval) so determine the version we will eventually be using
==> 41: version = new Workflow().getVersion(current.cat_item.workflow).sys_id + '';
42: }
43: wfs.setWorkflowVersion(version, current.context + '');
44: wfs.getChoices(current.stage, answer);
org.mozilla.javascript.EcmaError: Cannot convert null to an object.
Caused by error in <refname> at line 1
==> 1: sc_req_item_stageGetChoices()

Any help pointing in the right direction would really be appreciated.

[Brian Dailey1]

Hi Shawn,

The most obvious answer would be that it's something to do with how you are setting approval for the RITM.   The BR that kicks off the workflows won't start it until the RITM is approved.

If the parent REQ gets approved, it can cascade down to the RITM and the workflow will get started.   Perhaps limitations on the Guest account are preventing automatic approval of the REQ?   And you may have some client script or update BR on the RITM setting the approval to 'Approved' when you save it, which would explain why the Guest RITMs move forward once you save them from the form.

I would try setting the approval state of the RITM to Approved within your ordering script, and see if that makes a difference in the workflow starting automatically for Guest orders.

Thanks,

-Brian

Edit:   Also, look into that line 41 (from the BR) that is giving you the error:

                  version = new Workflow().getVersion(current.cat_item.workflow).sys_id + '';

I would create a copy of this BR (sc_req_item_stageGetChoices) for testing using Insert and Stay (temporarily set the original to inactive), and then breakdown this line into its components and log some troubleshooting data:

                  i.e., wrap everything in a try/catch block and check values for each of the following to see where it is failing:

                                      var wf = new Workflow();

                                      var itemWorkflow = current.cat_item.workflow;

                                      var version = wf.getVersion(itemWorkflow);

It also touches on several tables   ([sc_req_item], [sc_cat_item], and [wf_workflow_version]), you could look into the access for Guest to these tables, perhaps it is denying read access to a record resulting in a null value.

[Shawn Dowler · Accepted solution]

It turns out the issue was that I was working on a new workflow and I hadn't checked it in yet, so for the Guest account, it didn't exist yet. Once I checked in the workflow, it started working for everyone. I'm not used to having issues with this, since you can impersonate a user while working on a checked out workflow and ServiceNow makes your checked out workflow available to the user you are impersonating. Testing this in an inbound email action, which I've never had kick off a workflow before, meant that ServiceNow didn't see a connection between my admin user logged in and the guest user that the inbound email action was being run as.

Hopefully this might help someone else who can't figure out what is going wrong.

[Brian Dailey1]

Hmmm... I wasn't aware that a checked-out workflow was ever available, I thought it had to be published first (a.k.a, it would still use the old published version).   Good to know that could happen.

Thanks,

-Brian

[Mike McCall]

Same here: I did know that your checked-out workflow would work under your own account, but I don't think it would always carry over to other users while impersonating them.

If that works now, that's great!