If you’re just starting your Next Experience journey, then you’ve come to the right place. This guide (Next Experience Quick Start Guide – ServiceNow Community) will help you understand what Next Experience is, how it works in tandem with our Workspace UI, and is a great place to return to as our products evolve over time.
Before you get started
Before you get started with Next Experience, check and consider the following documentation:
Next Experience – ServiceNow Community
Workspace Getting Started FAQs – ServiceNow Community
Basic Overview on Migrating to a Configurable Work… – ServiceNow Community
How to use UI Actions in Workspaces – ServiceNow Community
ServiceNow did an amazing job introducing workspace into our world, the links above are kind of live savers, they are so well documented full of best practises, recommendations and tips.
Current scenario
I am going to improve the “Response Tasks” on the Risk Portal. This our view from the backend (https://instance.service-now.com/nav_to.do?uri=sysapproval_approver.do?sys_id=0f676330db361d1021e7dd18f496195d). We have 2 OOB UI actions for record manipulation (“Update” and “Delete”) and 2 UI actions to update the state (“Approve” and “Reject”).
This is our current view on Risk Portal (https://instance.service-now.com/now/risk/portal/record/sn_risk_response_task/809623fcdbf21d1021e7dd18f496198a/sub/record/sysapproval_approver/0f676330db361d1021e7dd18f496195d). We still have the OOB UI actions, but we are missing the 2 UI actions to update the state.
Steps
- Inspect the UI action “Approve” button to get the gsft_id.
- Clone the UI action for “Approve” and “Reject”.
- Create UX Form Action “Approve” and “Reject” and pointed to our custom UI actions. All these actions should be pointing to the sysapproval_approver table.
- Create a UX Form Action Group (or UX Actions Layout Group) called “approval actions” where type = Split Button and actions are Approve and Reject.
- In the UX Form Action Group record related items, create a new UX Form Actions Layout (sys_ux_form_action_layout_item) record. I named “Approval Actions” and this is responsible to display the button in the form.
- Through the related lists of the UX Form Layout Item record, create a new Action Layout record. Focus on the “Action Layout Items”, that’s the most important thing here. This connection must exist.
- The result will be:
Summary
The link How to use UI Actions in Workspaces – ServiceNow Community and Introduction to Declarative Actions – ServiceNow Community gave me enough to follow the breadcrumb trail and yes workspaces can be ready. We have few fields missing in the forms (we just need to update the view) and sometimes the UI actions do not behave the same but after few smoke tests the workspace can be ready. This is the perfect time to avoid lift and shift. This is a great o opportunity to re-imagine and improve the experience.
Bottom line is UI Actions are supported in both agent and configurable workspaces, but only in limited areas, such as the Action Bar component which is provided by default on the out-of-the-box record page. This means that UI Actions are only supported on forms in workspaces and not lists.
ServiceNow introduced a new concept called “Declarative actions”. What are they? Declarative actions are similar to platform UI Actions to add buttons on a form, etc. UI Actions are only exposed in the Action Bar component in Workspace, etc. experiences so the use cases are limited. Declarative Actions can be used in the Action Bar component on a record, related lists, lists, etc. without having to modify the page in UI Builder itself. By using Declarative Actions and not adding buttons to a page in UI Builder, you are making your upgrade experience better as Declarative Actions do not customize an OOTB UI Builder page. Instead, by creating Declarative Actions you are creating the necessary records needed in your own app scope.
