BR sometimes runs, sometimes does not

Russell Abbott · ‎05-23-2023

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 · ‎05-25-2023

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

View solution in original post

Ankur Bawiskar · ‎05-23-2023

@Russell Abbott

why not have this code in workflow run script if you are using workflow

OR

you can also do the same thing in flow designer with no scripting

Regards,
Ankur
✨ Certified Technical Architect || ✨ 9x ServiceNow MVP || ✨ ServiceNow Community Leader

Russell Abbott · ‎05-24-2023

This is how our initial build vendors set it up and I haven't really looked at moving away from the script to a workflow solution yet.

Ankur Bawiskar · ‎05-24-2023

@Russell Abbott

try this in after insert BR on RITM table

(function executeRule(current, previous /*null when async*/ ) {

	var grReqFor = current.request.getRefRecord();
	grReqFor.requested_for = current.variables.kpe_requested_for;
	grReqFor.update();
	current.requested_for = current.variables.kpe_requested_for;
	current.setWorkflow(false);
	current.update();

})(current, previous);

If my response helped please mark it correct and close the thread so that it benefits future readers.

Regards,
Ankur
✨ Certified Technical Architect || ✨ 9x ServiceNow MVP || ✨ ServiceNow Community Leader

Russell Abbott · ‎05-24-2023

Sent to the testing folks for further validation, a couple of REQ still came back incorrect. Can I ask why we need

current.requested_for = current.variables.kpe_requested_for;
	current.setWorkflow(false);
	current.update();

I'm probably misunderstanding what's taking place here but wouldn't the current record be updated by the first 3 lines cascading to the sc_req_item from the sc_request anyway?

Russell Abbott · ‎05-24-2023

The only way I have gotten this to work is by changing the BR to 'After insert/update'. Which isn't really what needs to happen.

Is this something that will better work if I add it in to the flow steps?