Redirect Records from Classic to Workspace

To ease the transition of users from Classic to Workspace, one of the solutions we use is a Business Rule and a Client script that redirects users who land on Classic pages to the same record in the new workspace.

I think context is important, so I’m going to go into a little bit of background before I dive into the technical details. If you want to jump to the technical solution, click here.

Initially, Serenity’s applications the fulfiller experience was designed for the ServiceNow Classic view (aka Core UI). In some areas of our applications, we planned for scalability, which resulted in architecture that required layers of records to tell the whole story of a Task.

To use an example from ITSM, if you think about a Change Request, it’s not just the main Change record that has all the important details, but also links to other records like Change Tasks, Configuration Items, Approvals, Incident, Problems, and SLAs.

For a seasoned ServiceNow fulfiller, this would be nothing new, but our customer’s end-users were loud and clear about their feedback. Most of them are not used to working tasks on a platform nor are they intimately familiar with relational databases. We got a lot of questions like: “Where am I? How did I get here? What do I do now? How do I get back to the [insert record type]?”

To help improve the user experience, our Product team decided to build out a Workspace for our processes. UI Builder gives you nearly unlimited control in crafting a curated experience for your users, and in our case, it helped make our many layers of records feel a bit flatter, which in turn made it easier to navigate and more efficient to work with.

We knew we weren’t going to be able to migrate all our processes to the Workspace in one release, so we planned incremental changes to transition the most used processes and records first. We’ve been migrating additional processes while also providing functional enhancements to the existing processes with each new release.

When you are implementing a transformative change like a new user interface, it’s important to take a multi-pronged approach. The following solution is just one of the enhancements we made to help end-users transition.

This article assumes that the Workspace features and functions have already been defined. Implementing the technical solution requires that the Workspace page names and required parameters have been defined.

Workspaces are usually designed for a specific persona. A Persona is a generalized representation of your target audience, capturing their behaviors, goals, needs, and characteristics to help guide product design and marketing efforts. For example, the Service Operations Workspace (SOW)  is designed for IT Service Management (ITSM) and IT Operations Management (ITOM) agents. These user interface with Incidents, Problems, Changes, and Configuration Items most frequently, so this workspace is designed to surface critical details from those records to allow efficient fulfillment of daily tasks.

Also, consider your specific environment. For example, is there a large population of users that would meet the persona of multiple Workspaces? There is a large overlap between record types viewed in ITSM and Customer Service Management (CSM) Workspaces, but the Workspace demographics might be different.

Once you have your persona(s) identified, then make an inventory of all the record types considered to be primary for these users. To use an example from ITSM, most ITSM and ITOM agents go to an Incident or a Change Request to view related records like SLAs, rather than going to and SLA just to navigate to the parent task. If you are stuck on how to get started, I suggest starting with unique record types from:

1. List menu items (both in your legacy Classic setup and in your Workspace).
2. Email notifications (or other communications) that provide direct links to records.

For example, Change Requests would be included because there are menu items pointing directly to the list of Changes. Change Tasks should also be included because individuals are assigned to them and will get direct links via email, even though there may not be a Change Task specific menu item for navigation.

Tasks are going to be a big chunk of the list, but there may be a few foundational data record types, like Users, Locations, or Configuration items.

A subset of the record types in your list, such as Users, are shared across many processes in the platform. If that’s the case, a simple redirect to Workspace may cause.

Organize your list into buckets based on how you expect your Workspace users to interact with the records. Keep in mind that this categorization is only considering what will happen if one of those Workspace users lands on the record in the legacy Classic view.

1. Always redirect – record types that should always be viewed in your Workspace. For example,
2. Conditionally redirect – record types that we might redirect in some cases but not others. For example, to view an Incident, an ITSM user might be redirected to the SOW, but a CSM user might get redirected to the CSM Workspace.
3. Manual or never redirect – records where the logic to choose the “right” redirect would be too complex or fragile. For example, you may not want to do anything with User records, and the likelihood of your Workspace users navigating to a User record in Classic directly is low.

For each item, consider how to you will determine the context details required to determine how and when to redirect. If it is not possible to define unique criteria for each redirect, an alternative solution would be to modify the script below for use in the UI Action to the user can manually decide which workspace to redirect to.

The solution is comprised of two parts for each record type. A Business Rule and a Client Script.

The Serenity applications  force a redirect on Workspace support tasks if the logged-on user does not have the platform admin role. As the record is loading in Classic, we evaluate role conditions and set a client-side variable to indicate whether a redirect is necessary.

Name: Redirect to Incident Center

Table: Incident [incident]

When: display

Order: 100

Advanced: true

Script:

Next the Client Script takes the information from the scratchpad, and does all the heavy lifting. For the example I’ve outlined, all of the information we collect in the Business Rule is also available on the Client side, and a few of the elements we have in the Client Script could also be evaluated in the Business Rule. In general, for optimal performance, you want to push everything you can to the Business Rule, so that it can be evaluated by the server before the page is even loaded.

Your mileage may vary depending upon the complexity of your conditions and whether they are accessible on the client side.

Name: Redirect to Incident Center

Table: Incident [incident]

UI Type: Desktop

Type: onLoad

Global: true

Isolate script: true

Script:

Frustrated because your users keep landing in the Classic view after implementing a Workspace? By employing a clever redirection mechanism with Business Rules and Client Scripts, users are seamlessly guided to the right page in Workspace. This ensures greater efficiency, reduces confusion and can help increase the initial adoption for a Workspace deployment. If you’re looking to elevate your users’ experience and streamline processes, explore our redirection solution and discover how to make the switch to Workspace a smooth one.