Problem:
g_modal in ServiceNow workspaces has a critical limitation: it fails to reflect user interactions from the pop-up back to the parent UI in real-time and the pop-up will not render based on the user Interaction if we create the pop-up using g_modal or ui page .
Description:
Traditional approaches like g_modal and custom UI Pages with Jelly scripting have significant drawbacks for modern ServiceNow workspaces. g_modal fails to render in Next Experience that are designed by using the UI Pages(Jelly Script). UI Pages demand heavy Jelly/HTML coding, poor reusability across workspaces, and maintenance.
Solution:
The modern declarative action method using OOB page working as “interceptor" and UX payloads overcomes these with no-code configuration, seamless UI updates via events/client state, full Next Experience compatibility, and rapid deployment for SOW/CSM workspaces. It leverages built-in modals for fields like reasons/comments, ensuring responsive design without scripting pitfalls.
ServiceNow offers out-of-box (OOB) workspace pages and the built-in "Resolve" declarative action using this exact approach.
This approach requires just three main steps:
- Create a Declarative Action of type UXF Client Action.
- Create a dedicated view for your specific requirement.
- Add the declarative action to UX Form Action layout items.
1.Create a Declarative Action of type UXF Client Action
In All Navigator, search for Declarative actions and click on form actions
Create new declarative action and select the table Name as incident and give the action label as On Hold and select implemented as UXF Client Action.
Now create one UXF Client Action and give the payload as follows ,
{
"route": "sowformmodalv2",
"fields": {
"table": "{{table}}",
"sysId": "{{sysId}}",
"title": "",
"view": "sow_incident_onhold_modal”
},
"params": {
"saveLabel": “On Hold,
"isGFormSave": true,
"setFieldOnLoad": {
"state": 3
},
"setFieldOnSave": {
"state": 3
},
"onclickAppseeEvent": "Click Incident Resolve Modal Action",
"modalTitle": "Resolve"
}
}The route parameter specifies the UI Builder page name—sowformmodalv2 refers to the out-of-box (OOB) page designed specifically to render forms in a popup modal.
The fields parameter includes the required inputs for this page:
- table: The target table
- sys_id: The record ID
- title: Form title
- view: The form view (critical parameter)
The view determines which UI Policies and Client Scripts apply to the popup. I've created a custom view tailored to my use case, so only its associated scripts and policies execute in the modal.
The params object holds optional parameters, such as:
- saveLabel: Customizes the save button text in the popup
- setFieldOnLoad: Pre-populates field values when the form loads in the pop-up (e.g., state: 3 automatically sets the state to "On Hold")
- setFieldOnSave: Sets field values after clicking the save button (triggers post-save)
- modalTitle: Overrides the modal's header title
Now add this new created UXF client action in the declarative action and save the declarative action.
Even though we created a declarative action, it won’t be visible until we add it to the UXF form action layout of that workspace
Type form action layout in the application navigator ,Click on that module and apply the filter as
As follows and open the record and there is a related list called UX Form action layout items ,click on edit and add the newly created declarative action.
Now the button is visible in the workspace but it didn’t work the reason is we didn’t add the Event mappings for that declarative action.Till now, we generated a payload in the UXF client action but we didn’t sent it to the UI Builder Page yet by creating the Event
Mapping.
To create an event mappings, open the declarative action which we created and click on advanced view related link and we will see one more related list will be visible named as UX Add-on Event Mappings and click on new and add the fields as shows in the following image,
Target Event Payload mapping is same as like what we give for the payload mapping for the Uxf client action, from uxf client action we are generating the payload and mapping that payload using this event payload mapping to UI Builder page.
{
"container": {
"fields": {
"binding": {
"address": [
"fields"
]
},
"type": "EVENT_PAYLOAD_BINDING"
},
"params": {
"binding": {
"address": [
"params"
]
},
"type": "EVENT_PAYLOAD_BINDING"
},
"route": {
"binding": {
"address": [
"route"
]
},
"type": "EVENT_PAYLOAD_BINDING"
}
},
"type": "MAP_CONTAINER"
}Now save it and observe the button in the Workspace it will function properly.
Conclusion:
The main aim of this article is ServiceNow developers no longer need to wrestle with complex Jelly scripting or the outdated g_modal for workspace popups, especially for sophisticated requirements that trip up many teams.
The Modern Approach: Create a dedicated form view, then apply standard UI Policies and Client Scripts to it. Every developer already masters these familiar tools—no Jelly expertise required!
This declarative method handles complex popup logic cleanly within UI Builder workspaces.
