Get a first look at what's coming. The Developer Passport Australia Release Preview kicks off March 12. Dive in! 

Issue imitating an out of box UI action

Casey Verhagen
Giga Guru

Hello,


I am trying to replicate the logic of the out-of-box UI action on sc_request called "Cancel Request".

URL: https://<yourinstance>.service-now.com/now/nav/ui/classic/params/target/sys_ui_action.do%3Fsys_id%3D...

 

The logic in that UI action is pretty simple:

 
current.request_state = 'closed_cancelled';
current.stage = 'closed_incomplete';
current.update();
 

I've created a UI action on the sc_task table using basically the exact same logic, except I'm querying the request because dot walking didn't seem to work:

var req = new GlideRecord('sc_request');
if (req.get(current.request)) {
        req.request_state = 'closed_cancelled';
        req.stage = 'closed_incomplete'; 
        req.update();
}

 

Regardless of which UI action I use, the result is that the state and stage fields of the RITM are set correctly. But the way the stage is displayed in the list view is incorrect. You can see in the below image, that the red X indicates that RITM has been cancelled, vs the top request shows that fulfillment was completed and closed cancelled was skipped.

ui action.png

 

So something isn't quite behaving in the custom UI action like it does when using the out of box action, and I'm hoping someone might be able to shed some light on this, or at least point me in the right direction to figure out what I'm missing here.

 

TIA!

5 REPLIES 5

lauri457
Tera Sage

Are those two ritms the same catalog item with the exact same work/flow? Cancelled at the same point in the flow? And what do the flows look like? 

 

Consider this oob flow, it's been cancelled with the ui action in stage order fulfillment while the task is still open. 

Screenshot 2026-02-25 113120.png

 

Order fulfillment shows up completed and request cancelled step is skipped because the br will just cancel the flow and the flow stage will never happen so it is misleading.

Screenshot 2026-02-25 113308.png

I don't see any reason why the behaviour would be different from your ui action because they do exactly the same thing. Unless there is something else in the custom ui action of course

Yes, the two catalog items are the same. The workflow is pretty simple. Request submitted > Approval 1 > Approval 2 > TASK created. I'm cancelling after the task has been created.

Without access to your instance it's hard to say what is happening but it does not matter if you do the update from another form via this ui action.

 

There could be some customization that makes it only work as expected when the current.update() in the request ui action captures all the changes on the form which wouldn't happen from sc_task.

 

What happens if you just run this as a background script? If it works as expected then start looking in the sc_task side of things and if not then look into sc_request 

var req = new GlideRecord('sc_request');
if (req.get("sysid")) {
        req.request_state = 'closed_cancelled';
        req.stage = 'closed_incomplete'; 
        req.update();
}

 

Tanushree Maiti
Tera Sage

Hi @Casey Verhagen 

You have written that you have updated logic in sc_task but in shared code  - update is on sc_Request !!

Your request showing stages' mismatch on RITM table (sc_req_item). 

 

Correct it. it will work.

Please mark this response as Helpful & Accept it as solution if it assisted you with your question.
Regards
Tanushree Maiti
ServiceNow Technical Architect
Linkedin: