UI Action working in Native UI but not triggering on Configurable Workspace (Problem Table)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
7 hours ago
Hi @community
I have a custom UI Action on the Problem (problem) table that validates child Problem Tasks (problem_task) before allowing a state transition.
Expected Functionality:
When a user clicks the UI Action to move the Problem record to the next state, the script checks whether any associated problem_task records are still active/open:
If active ptask records exist -> Show an error/alert message and prevent the state change.
If all ptask records are closed/inactive-> Advance the Problem state to the next state.
The Issue:
This UI Action works as expected in the Native UI, but when executed from the Workspace view, the validation does not work (or the state transition fails/bypasses the check).
Could someone advise on how to properly structure this UI Action for Workspace compatibility?
Do I need to configure the Workspace Client Script field separately?
What is the best practice for performing a synchronous/asynchronous GlideRecord or g_scratchpad check on child tasks in Workspace?
Any code snippets or guidance on setting up the Client vs. Server execution for Workspace UI Actions would be greatly appreciated!
Regards,
Asish
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
6 hours ago
Hi @Asish17 ,
1.You need to configure the Workspace Client Script field separately.
2.Refer BLOG - Handling OnSubmit Validation Without getXMLWait() in Native UI, Workspace & Portal for implementing the server-side call using a Script Include.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
5 hours ago
Hi @Asish17
Yes. For Configurable Workspace, use a Declarative Action. Keep the validation on the server side rather than using client-side GlideRecord/g_scratchpad.
Example server-side logic:
var pt = new GlideRecord('problem_task');
pt.addQuery('problem', current.sys_id);
pt.addActiveQuery();
pt.setLimit( 1 ) ;
pt.query();
if (pt.hasNext()) {
gs.addErrorMessage('Cannot move the Problem forward. Active Problem Tasks exist.');
action.setAbortAction(true);
} else {
current.state = /* next state */;
current.update();
}
So the pattern is:
Declarative Action (Workspace) > Server-side validation > Update state
No need to duplicate the validation in a Workspace Client Script unless you specifically need client-side UI behavior.
If you found this useful, feel free to mark it as Accept as Solution and Helpful. It makes my day (and helps others too 😉).
Regards,
- Ankit
LinkedIn: https://www.linkedin.com/in/sharmaankith/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 hours ago
share your UI action config screenshots and scripts here
Ankur
✨ Certified Technical Architect || ✨ 10x ServiceNow MVP || ✨ ServiceNow Community Leader
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 hours ago
Hi @Ankur Bawiskar ,
Thank you for your reply 🙂
UI Action Name - Resolve
Table - problem
Action name - move_to_resolved
onClick - onResolve()
condition - current.canWrite() && (current.state != ProblemState.STATES.RESOLVED) && (current.state == ProblemState.STATES.FIX_IN_PROGRESS) && new ProblemStateUtils().validateStateTransition(current, ProblemState.STATES.RESOLVED) && (gs.hasRole('problem_manager') || gs.getUser().isMemberOf(current.assignment_group))
Script -
