The fundamental purpose of Workspaces in ServiceNow is to enhance the agent experience by consolidating relevant records, tools, and workflows into a single, unified interface. This reduces context switching, improves efficiency, and increases overall user satisfaction.
However, this experience breaks down when agents are required to work on both Cases and Incidents. Although Incidents are visible within the CSM Workspace, agents are unable to perform critical actions such as state transitions or operational updates. These actions are available only in the Service Operations Workspace, forcing agents to switch workspaces to complete basic tasks—undermining the very goal of the Workspace model.
This limitation highlights the need to surface Service Operations Workspace (SOW) actions within the CSM Workspace, allowing agents to manage both Cases and Incidents seamlessly from a single interface.
This article walks through a recommended and supported approach to bringing SOW actions into the CSM Workspace (or any Workspace) without modifying high- or medium-risk out-of-the-box files, ensuring upgrade safety, maintainability, and alignment with ServiceNow best practices.
To be specific, in this article, we are going to bring Incident actions to the CSM Workspace
Steps taken to achieve the SOW actions functionality in CSM Workspace:
- Create a View Rule.
- Create a UX Form Action Layout.
- Configure the Record page of workspace.
- Add the SOW Modal page collection to the Record page.
- Add UX Event Mapping to each Declarative Actions.
1. Create a View Rule :
• Out of the Box, The Incident buttons that are available in SOW are made to be visible only in the 'Service Operations Workspace' view.
• In the CSM/FSM Configurable Workspace, the Incident record opens in the 'Workspace' view, which doesn't make it available in here.
• We could remove the view for those buttons, but those buttons are often High-risk files, altering them is not recommended.
• Alternatively, we can create a UX Form View rule to open the Incident record in 'Service Operations Workspace' view within the CSM/FSM configurable workspace.
• Navigate to All > UX Form View Rules
• Create New
• Fill the required fields as per the image above.
• Under the Related List, Add the CSM/FSM Configurable Workspace View Rule Config.
After this is done, the Incident record will now open in the 'Service Operations Workspace' view.
2.Create a UX Form Action Layout:
• Form Action Layouts define the set of Declarative Actions that are available for a specific table within a particular Workspace. They determine which actions are exposed to the user and how those actions are presented in the Workspace interface.
• Navigate to All > Form Action Layouts
• Create New.
• Select the table as Incident and Add 'CSM/FSM Configurable Workspace Action Config' to the Action Config field.
• In the Related List, UX Form Action Layout Items, click on Edit and select the buttons that you need for the Incident table.
After this configuration, you would be able to see the actions on the Incident record. But notice, nothing happens when you click on them.
3.Configure the Record page of workspace:
• Navigate to All > UI Builder.
• Under Experiences, Select the CSM/FSM Configurable Workspace.
• Under the Pages and Variant, Select the 'CSM Default record page' and Duplicate it.
• Go to the Settings tab of the duplicated variant and Under 'Open records' drop-down, click on Page Definition.
• Scroll down to the Handled Events field, select the "[SOW] Open Record form modal v2" event.
• Save the form.
• Come back to the Editor, Now under the Content left pane, click on "Body".
• In the right pane, click on Events tab.
• Under Page Event Mappings, Click on "Add event mapping".
• Select the "[SOW] Open record form modal v2" event and Click on "Add handler".
• Select the "[Record Page] Open modal".
• Switch to Script from the dropdown and add the following code.
/**
* @Param {params} params
* @Param {api} params.api
* @Param {any} params.event
*/
function evaluateEvent({api, event}) {
const eventPayload = {
route: event.payload.route,
fields: event.payload.fields,
params: {
...event.payload.params,
parentFormFields: api.data.record.form.fields
}
};
if(event.payload.size) {
eventPayload.size = event.payload.size;
}
return eventPayload;
}
4. Add the SOW Modal page collection to the Record page:
• Open the Record page Editor.
• Click on "Modal Container (Viewport)" under Modals in the left pane.
• In the Right pane, click on the "Add" button beside Page collections.
• Select the "SOW Record page modals" from the popup and click on "Add".
5. Add UX Event Mapping to Each Declarative Action:
• Navigate to All > Now Experience Framework > Declarative Actions > Form Actions
• Open any Action on the Incident table that needs to be added (For Example, Resolve).
• A form will open.
• Under the "UX Add-on Event Mappings" Related List, Click "New".
• Give the Name, Description.
• In the Source Element ID, type "ui_action_bar".
• The Source Declarative Action is already pre-populated.
• In the Parent Macroponent, give the Record page variant that was created.
• Select the "[SOW] Open record form modal v2" under Target event.
• Copy the Target Payload Mapping from the existing UX Add-on Event Mapping record.
{
"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"
}• Submit the form.
• Repeat this process, for each button that needs to be available in the CSM Workspace.
After completing these configurations, the buttons will behave exactly as they do in the Service Operations Workspace.
This approach allows agents to manage both Cases and Incidents from a single Workspace—improving efficiency, consistency, and overall agent satisfaction—while preserving the integrity of out-of-the-box functionality.
Mark this article as helpful if you find so!
