BR sometimes runs, sometimes does not

[Russell Abbott]

I have a BR (noted below) that runs on insert. Maybe one in 6 or so attempts, it seems to not run.

It is designed to update the 'requested_for' field on sc_request, with the 'requested_for' variable on the 'Requestor Variables' variable set.

If I compare two sc_requests, one that was successful and one that was not, and look at the record history. I can see an audit entry in the successful record, with the corresponding old value/new value.

The unsuccessful record has no such entry.

Can I tie that audit record back to a clientscript or business rule? I have search for competing scripts/rules and come up with nothing.

The BR below only runs on insert, it does have current.update, which should be ok correct?

Any suggestions would be appreciated!

(function executeRule(current, previous /*null when async*/ ) {
    var grReqFor = new GlideRecord("sc_request");
    grReqFor.addQuery("sys_id", current.request);
    grReqFor.query();
    if (grReqFor.next()) {

        grReqFor.requested_for = current.variables.kpe_requested_for;
        grReqFor.update();

    }
	current.requested_for = current.variables.kpe_requested_for;
	current.update();

})(current, previous);

9

[Weird]

Don't do current.update() as that can cause issues. For example in some cases another BR might abort the update.

You should log your scripts to see if they run correctly.
gs.info("Request test: " + current.number); before var grReqFor (for example) and you can check the log table to see if the BR ran.

For requested_for you should try changing the variable name to requested_for. It should automatically map it to the correct field on the RITM and the Request.
You can keep the old variable in the background and simply add a UI Policy or client script on the catalog item and make it hide the old variable so you don't "lose" any data that you might already have.

[Russell Abbott]

The requested_for variable has a different name from the initial build that our contracted vendor set up. That name is referenced in some Script Includes and other places so I hadn't been too concerned about changing it, although I will keep it in mind for future

Logging the script is a great idea and I used that to make sure I was looking at the correct BR. I was, I commented out the current.update lines and at first I thought it had fixed the issue, after further testing I'm still getting Requests created where the 'Requested For' is not copied correctly from the record producer (kpe_requested_for) variable.

I had read in another thread that current.update was OK to have on an Insert BR. I guess that's not always the case.

[Weird · Accepted solution]

Using current.update() is unnecessary due to the fact that Servicenow already saves all value changes after the BR script has run. If you add a current.update() you're basically potentially triggering all on update BR's again and again.
I'm not sure how exactly it would behave in insert as the update technically inserts the record, but I'd say yes.
one option is to add current.setWorkflow(false) before current.update() but that potentially blocks important script from running, so it's not ideal either.

I think your main issue is with the fact that you might not have a related request at that point.
The request is generated at about the same time with the request items and the relation might not exists when you run your first on before BR. I believe I had a similar issue before, but that was a few years ago. 

Try changing your (on before update) BR so that the order is over 1000.

There's a certain order on how things are done in servicenow and BR's order affects when it's run.
It might not however be enough.

What kind of logging did you do? How about logging this inside the if

gs.info("Request number: " + grReqFor.number);

If you don't get the number for the cases that fail, then that means that the request wasn't related to the ritm at that point.

You might be able to solve this by creating a on before script on the request table.

(function executeRule(current, previous /*null when async*/ ) {
var ritmFor = new GlideRecord('sc_req_item');
ritmFor.addQuery("request", current.sys_id);
ritmFor.query();
if(ritmFor.next()){
current.requested_for = ritmFor.variables.kpe_requested_for;
}
})(current, previous);

 If however that also isn't working then you'd have to either create a after update BR or modify the workflow to do that.

Basically you can keep the on before BR to update the current record with this if you leave the update out.

current.requested_for = current.variables.kpe_requested_for;

 Then as an after rule you can add the update for the request. Or you can add the same script to the beginning of the workflow. Workflow scripts always run current updates kinda like on before. 
Actually, I believe the run order is

* Before BR with order < 1000
* Workflow
* Before BR with order > 1000

[Russell Abbott]

I added the log line to capture the REQ number as you suggested and indeed the relationship was not yet being created (no REQ number was captured in the log). I changed the run order of the BR to 2,000 and that seemed to fix the issue, now I'm seeing the log show the REQ number and I'm seeing the name populate correctly! The BR is set to Async - Insert, as it was when I found it, and it seems to be working this way