Workspaces are being used more and more in ServiceNow, but it is often overlooked that each workspace was developed for a specific purpose and a specific target group. However, this also means that a workspace is not a substitute for all the possibilities of the Classic UI.
A popular question in the community is therefore how to get the familiar "Edit ..." button from the Classic UI for workspaces as well. And as a typical use case, I would like to use the related lists on records from the sys_user table:
As you can see in the above screenshot, it is possible to open records from tables like sys_user the Service Operations Workspace (or any other Configurable Workspaces) was not designed for initially. You can navigate through the records, however the "Edit ..." button is missing.
Now you might think: "Wait, there is a generic "New" button OOTB, why don't we also have a generic "Edit ..." button"? To be honest, this is a pretty good question I cannot answer. In the Classic UI we have that generic "Edit ..." button, and perhaps ServiceNow will deliver this button for Configurable Workspaces at a later date. Until then, we need our own solution, and before I get to the implementation, I need to briefly explain why this "Edit ..." button exists at all ...
The 'Related Records' tab summarizes three different types of related lists. Although they all appear as individual tabs/lists, they are technically distinct:
(1) Relationships
Having a relationship means that there is no table in between the left and the right table. Instead, a script relates the records of both tables:
On such a related list, ServiceNow cannot provide any buttons, as only the relationship decides which records are displayed.
(2) One-to-many references (o2m)
This is the most common relationship between two tables and is represented on one side of the arrow by a field that contains a reference as a Sys ID to a record in another table:
On these related lists, at least a "New" button is provided, to create new "child" records which reference automatically to their "parent" record.
(3) Many-to-many references (m2m)
If each record in the left table can have any number of references to records in the right table and vice versa, you need an intermediate table in which these relationships are stored. A very well-known example of this is the associations between a user and his roles. Each user can have any number of roles, and each role can be assigned to any number of users.
On these related lists, the "Edit ..." come into play. For a certain record from the left table (e.g. a certain user) a so-called slushbucket dialog is then offered which allows selecting records from the right table (e.g. roles). After clicking on "Save" / "Ok" ServiceNow manages in the background adding or removing the respective records in the intermediate table:
Implement the "Edit ..." button
Now let's start with the implementation of the "Edit ..." button finally. If you want to have buttons anywhere on a Workspace, you basically have two options:
- Reuse classic UI Actions
- Implement from scratch
For the first option, there is a great article: How to use UI Actions in Workspaces
After reading this article, you may be disappointed to learn that the classic UI Actions in ServiceNow have severe limitations when it comes to enabling the required 'Edit...' button. Although ServiceNow has attempted to bridge the gap between the old world (Classic UI) and the new world (Next Experience), it is only possible to enable classic UI Actions on the form view and not on (related) lists.
Therefore, only an implementation from scratch comes into question.
In Workspaces, buttons are called "Declarative Actions" and they are embedded into a network of many different tables and relations. If you want to fully understand the underlying concept, I recommend the excellent article Declarative Actions in ServiceNow: The COMPLETE Guide
But does the occasional developer really want to invest several hours of work each time for creating a dozen records just for a simple "Edit ..." button? I don't think so. For this reason, I have been looking for a solution where you can create a new "Edit ..." button with only a single new record.
To shorten the whole thing: I decided to leverage the well-known slushbucket dialog from the Classic UI. That dialog can be invoked via page /sys_m2m_template.do. And with a series of URL parameters, this dialog can be configured so that it reads the data from the correct tables and fields and writes it back accordingly when saving.
To create a new button for the "Roles" related list open module Workspace Experience -> Actions & Components -> Related List Actions and click "New".
The upper part of the form can be filled as follows:
In the section "Conditions" fill the following values into the highlighted fields:
⚠️ Note:
The second part of the condition parent.getTableName() == 'sys_user' is important to restrict the visibility of the "Edit ..." button to the user form. Otherwise, the button would also appear on the "Users" related list on the form view for records of table sys_user_role. If you also want an "Edit ..." button for roles, you need to create a separate record.
The most important part is represented by the script:
As you can see, the previously mentioned page /sys_m2m_template.do along with a series of additional URL parameters is opened in a new tab. The parameter values correspond to the respective attributes of referencing m2m table construct.
For easier transfer to your implementation, here is the code in plain text:
function onClick() {
var _strLink =
'/sys_m2m_template.do?' +
'sys_is_list=true&' +
'sys_is_related_list=true&' +
'sysparm_collectionID=' + g_form.getUniqueValue() + '&' +
'sysparm_query=&' +
'sysparm_referring_url=' + location.pathname + '&' +
'sysparm_stack=no&' +
'sys_target=sys_user_has_role&' +
'sysparm_m2m_ref=sys_user_has_role&' +
'sysparm_collection=sys_user&' +
'sysparm_collection_key=user&' +
'sysparm_collection_label=Roles&' +
'sysparm_collection_related_field=role&' +
'sysparm_collection_related_file=sys_user_role&';
var win = top.window.open(_strLink, '_self');
win.focus();
}
Get rid of the "New" button
For the "Roles" related list, the OOTB "New" button is not helpful and thus should be hidden. This button is built by a declarative action on the global table, and the easiest way to identify it is using the following URL:
/nav_to.do?uri=sys_declarative_action_assignment.do?sys_id=5555b77273131010a0a79329faf6a780%26sysparm_view=advanced
Go to the related list "Action Exclusions" and add a new record for the table sys_user_has_role:
Now we are done and only the recently created button "Edit ..." should be visible:
