Introduction

On a ServiceNow Instance, a user can order items from the Service Catalog and store these items in the Shopping Cart. When we submit the cart, a Request [sc_request] record is generated and each of the items that were submitted in the cart will generate into Requested Item [sc_req_item] records.  

The Requested Item[sc_req_item] will then trigger their own workflows as soon as the parent Request "Approval" field is set to "Approved"

Due to the design of the Service Catalog, the child sc_req_item record is created in the database before the parent sc_request is.

Scenario

There is a scenario where a user has set up a configuration to have the Request auto-approve, so that the Requested Item [sc_req_item] workflows trigger immediately upon submission.

In this case, this can cause an issue where "Unique Key Violation" errors can occur if the first activity in the workflow for the Requested Item [sc_req_item] is the following:

updateRequest();
function updateRequest() {
  var gr = new GlideRecord("sc_request");
  gr.get(current.request);
  while (gr.next()) {
    gr.short_description = "test";
    gr.update();
  }
} 

While the APIs used here are supported, executing a script above can conflict with the logic of the Service Catalog in two ways: 

1. If this script was to execute at the time when the data of the parent Request has not been committed to the database, the GlideRecord() API will perform an INSERT into the Request [sc_request] table. This behavior can cause a unique key violation error.
2. If the above script is run during the process of the Request [sc_request] creation, then the business rules running on the Request [sc_request] and Requested Item [sc_req_item] will run as a recursive business rule. This is the same logic as executing a "current.update(); and it is to be avoided at all cost.

Resolution

If there is a business logic to update the Request [sc_request] record, then a workflow timer can be included just before the "Run Script" activity in the workflow that includes the code above. The timer is beneficial for two reasons:

1. The timer allows the business rules to complete their execution before the Run-Script logic is then invoked.
2. The timer allows the Run-Script and any other business rules/script-include to run asynchronously as a Scheduled Job [sys_trigger] and therefore runs as a system user, which can allow better performance.

For more information on how a Workflow Timer can assist in script execution, please refer to KB0647534 - Workflow Engine | How does a Workflow Timer help? for more information.