'Create Request' UI Action acting differently in custom Workspace - Displaying Create New Cat Item
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
29m ago
We are working in ITSM, with the Service Operations Workspace (SOW) installed and functioning. We have created a separate custom workspace Service Desk Workspace (SDW) that is similar.
Both display Interactions, both have a similar action bar with: Save, Create Incident, Associate Record and Create Request. The first three work normally, but in the SOW, the 'Create Request' button opens the service catalog (see screenshot).
While in the SDW, the same UI Action opens a 'Create New Catalog Item' view (see screenshot).
Both Workspaces use the same UI Action, so both are calling the same script:
function onClick() {
var result = g_form.submit('sysverb_ws_save');
if (!result) { // failed form submission
return;
}
result.then(function() {
var params ={};
params.sysparm_parent_table = "interaction";
params.sysparm_parent_sys_id = g_form.getUniqueValue();
g_service_catalog.openCatalogItem('sc_cat_item', '-1', params);
});
}This is a standard script that has been discussed elsewhere in the community and docs.
(I did note that the 'Create Request' UI Action was in the 'Record Page for Service Operations Workspace' and tried to creating a new UI Action in the Global space where the SDW lives, but there was no change in results.)
The URLs for both are essentially identical other than the workspace used, so the parameters being handed in are the same:
SOW: /now/sow/record/interaction/0b1ead68935813504078f1f52603d6d1/sub/record/sc_cat_item/-1_uid_5/params/extra-params/parent_table%2Finteraction%2Fparent_sys_id%2F0b1ead68935813504078f1f52603d6d1%2Fsysparm_parent_table%2Finteraction%2Fsysparm_parent_sys_id%2F0b1ead68935813504078f1f52603d6d1
SDW: /now/service-desk-workspace/record/interaction/0b1ead68935813504078f1f52603d6d1/sub/record/sc_cat_item/-1_uid_7/params/extra-params/parent_table%2Finteraction%2Fparent_sys_id%2F0b1ead68935813504078f1f52603d6d1%2Fsysparm_parent_table%2Finteraction%2Fsysparm_parent_sys_id%2F0b1ead68935813504078f1f52603d6d1
(Note: the suffix number in the parameter -1_uid_x seems to be random. It changes between runs and if I change the URL to reflect, I get the same response on both workspaces.)
There is one clear difference I have found: The SOW has an Action Assignment entry that appears to be a link between the SOW and the UI action. The SDW does not, so I'm thinking there might have been some process and/or underlying data that exists for the SOW that created the Action Assignment entry (and maybe other pieces I haven't found yet), that was not used for the SDW.
Any ideas where else to look?