Introduction

It seems like every release brings with it a new Workspace, and with it either some new functionality or a shiny new coat of paint over some familiar capability. With the introduction of the Next Experience in the San Diego release, ServiceNow began the parade of “Configurable Workspaces,” or “Experiences,” that have now become the vehicle for enabling enhanced AI and other advanced capabilities on the platform.

Here we will look at the state of these Workspaces and how they impact the usage, architecture, and design of solutions for ServiceNow. For more detailed information, see the ServiceNow documentation: Next Experience UI (servicenow.com).

Workspace Overview

Prior to the Next Experience, ServiceNow dipped their toes in the enhanced UI waters by introducing the Agent Workspace (and the ability to create your own Workspaces using the framework). This would lay the groundwork for introducing what we now know as “Configurable Workspaces,” but as of the Washington DC release is no longer shipped, supported, or available for activation. Thus, for the remainder of this article the term “Workspace” is used to refer to the Next Experience configurable workspaces.

The Next Experience uses an implementation of “Web Components” (learn more about Web Components here) to encapsulate functionality within discrete units on a page to achieve the following benefits:

1. Allow complex functionality to be packaged into self-contained and reusable units
2. Avoid code sprawl encountered when reusing controls that require complex HTML, scripts, and styles
3. Prevent conflicts between different implementations of similar blocks of code where styles or events and functions may overlap

Each component functions in a similar way to an “Interface” (see this page for a good description of interfaces in object-oriented programming) in that it defines a set of inputs (if necessary) and returns a set of outputs (also if necessary) while leaving the details of how the functionality is implemented up to the internal code. It is, in other words, a promise of a specified or agreed upon result but not a promise of how that result is achieved. This means that any JavaScript library can be used to implement the code within the component. And this is precisely why the Next Experience was built using this methodology: the internal workings of the component can be changed in any future release to use more efficient, simpler, or just different libraries without the platform needing to be entirely re-architected. The component is effectively future proofed as long as the new implementation uses the same inputs and outputs and returns the same result.

That is a big deal.

However, it’s important to note that, as of this writing, Workspaces are not meant to replace every UI on the Now Platform. There are now three primary interfaces in ServiceNow: Service Portal for the end-user experience; Workspace for the fulfiller experience; and what is now known as “Core UI” (or the “backend” or the “admin UI” or the “frameset UI” or… well, it goes by many names) for System Administration as well as other Fulfiller processes that have not yet been gifted with their own workspace (emphasis on “yet”).

Workspaces do not yet support the “responsive” layout that Service Portals offer, and with continued development on several portals (Employee Center and the Customer and Consumer Service portals, for example) it does not appear that there is any rush to replace Service Portal with the Next Experience just yet.

Now that we understand a bit more about Workspaces, let’s look a little closer at some of the benefits and challenges they present.

The Promise of Workspaces

Going back to the Agent Workspace, the concept of a dedicated space that would ease access to information and supercharge productivity was the driving force behind introducing this new user experience paradigm. The idea was to encapsulate the various things a fulfiller would need to do work while remaining in a single browser tab. From a focused landing page and a targeted set of record lists to a structured work area that could use nested tabs to ease navigation without losing your place, the promise of Workspaces was to simplify the fulfiller experience under a single pane of glass (I promise that’s the last time I’ll use that term in this article) to make work as efficient as possible.

Often fulfillers need additional context when working on a task, such as information about a user, configuration item, Customer Account, or other related entity. Workspaces offer a consolidated view of this related information by either presenting it as a sidebar for the current record or allowing related records to open in a new tab within the same page so that users don’t have to navigate away from a record or open a new browser tab (which affects the browser’s history stack and can often cause frustration when the “back” button takes you somewhere you didn’t expect).

Additionally, most of the new capabilities (including the fast-expanding GenAI solutions) are exclusively released for and accessible from the new Workspaces. Now Assist, Playbooks (the portions for fulfillers), Recommended Actions, and other capabilities are not accessible in the Core UI, so adoption of these capabilities will also require adoption of Next Experience Workspaces.

If you have not already at least explored the various Workspaces, now is a good time to get started as they will only become more ingrained in the platform.

The Challenge of Workspaces

Every ray of sunshine casts a shadow, and it is no different with Workspaces. Along with all the promise, benefits, and new capabilities come real, and not insignificant, challenges to adoption, development, and maintenance.

Challenge 1: Silos and Sprawl

Considering users first, one of the main challenges of adopting Workspaces is the sheer number of them. Each workspace is designed for a specific Persona and Use Case, and the functionality is designed to support it. Unlike Service Portals, where any page can be used within any portal, each page (and with it, the functionality offered by the page) in a Workspace is defined only for that Workspace and cannot be used or accessed from elsewhere. This poses significant usability challenges when a user’s responsibilities cross multiple personas. In these cases, they may have to toggle between multiple Workspaces as they work through their processes.

A specific example relates to the intersection of Request Fulfillment and Asset Management. For many organizations, the Service Desk (the consummate IT Fulfiller) is responsible for fulfilling hardware and software requests for their end user base. Along with this responsibility, they may also manage stock for the equipment they provide. So, what happens when a user requests a new laptop?

Well, when Procurement is in use the first thing to happen (after approvals) is a “Sourcing” task for the entire Request. This task is meant to identify how the requested hardware will make its way to the fulfiller to supply to the requester. The request may be fulfilled from local stock, it may require transfer from another stockroom, or it may need to be purchased from a supplier.

As a result of such purpose-built workspaces, it can often be a challenge for a user to know where they need to be for a specific task or a specific step in a larger workflow. Clear and accessible documentation along with good training can help mitigate this risk, as well as some clever design to try to bridge across Workspace silos, such as providing navigation options when a task is best worked in another Workspace.

It may also be possible to mitigate some of this conflict by adding capabilities to other workspaces, however this would require a non-trivial level of effort to “copy” a page and its functionality from one Workspace to another. The copied pages and other artifacts would also need to be kept up to date with changes to the source page.

Challenge 2: Self-Configuration

Beginning with Homepages, one of the most powerful capabilities that ServiceNow offers is the ability to empower users to create what they need to be as productive as they can. Being able to build targeted reports, consolidate them onto a page, and share them with your team has been a mainstay of the platform since its inception, and is the main reason I fell in love with it so many years back. It was the root of my career transformation and the inspiration for my mission to spread that transformation as far and as wide as I can.

Now let’s talk Landing Pages. Each Workspace hosts a Home or Landing page, and it is possible to create “Variants” of the landing page that can be surfaced to a user depending on the roles they have (we will talk further about Variants a bit later). The Landing page is meant to provide key data for the user upon entering the Workspace to help answer the question “What do I need to work on next?” So, it would seem this is akin to Dashboards. But alas, this is not the case.

Landing pages, while they support Variants, are not adjustable or sharable by the user. Each Variant must be built by someone with what amounts to administrative access within the Workspace. Dashboards are still accessible though the Platform Analytics Workspace (see the documentation for more information), and it is possible to add Dashboards to a dedicated page within a Workspace (see the documentation for a specific implementation for the CSM Configurable Workspace), but given the newly siloed nature of Workspaces (see Challenge 1) it is no longer as intuitive or seamless.

Workspaces do still offer a level of personal configuration, specifically by allowing you to define your own “Lists” for quick and specific access beyond what is configured for the Workspace in general. The interface also still allows you (for the most part) to configure list layouts and to personalize forms, and certain pages offer personalization or configuration preference options depending on the page content. However, the loss of quickly and easily creating and sharing Dashboard content is a big one.

There are not a lot of options available to mitigate these challenges, other than providing good training and documentation to ensure users know where to find things like Dashboards and understand what they are able to configure themselves. You can also look to add a “Dashboard” page to each Experience, which will ensure that users remain in the experience when clicking through any report content to view the lists and records.

Challenge 3: Development and Maintenance Complexity

ServiceNow released UI Builder as a way to configure and develop within the Next Experience framework. They also allow building custom components (although they generally discourage this). However, building a custom component requires significant additional expertise and advanced tooling, as components must be built off-platform in a command line interface or other IDE, that most seasoned platform developers and architects do not have. And for many of us, the learning curve is a bit too steep.

The power and promise of ServiceNow is that it obscured the underlying complexity of building an Enterprise-grade application and allowed folks with moderate scripting abilities to build amazing experiences. Next Experience introduces an entirely new lexicon along with purpose-built architecture that looks similar to, but is distinctly different and separate from, familiar entities like Script Includes and UI Actions.

One need only attempt to explore an existing page in a Workspace to quickly grasp the complexity and multi-layered architecture upon which many pages are built. Often sub-pages are nested within a Viewport in an existing component, and that sub-page may contain additional viewports wherein additional pages are nested, and so on. It is often a struggle to locate the component you are looking to investigate.

Additionally, the nature of Page Variants can make testing a challenge. Each Variant is given an order within a page route, and the first variant for which a user matches an Audience (as well as a match on any page conditions) will display when accessing that route. As an administrator, it can be difficult to access a particular Variant when testing, as the “all roles” nature of the admin role means that you will likely match the Audience of the first Variant by order. That fact can make changes to a variant somewhat difficult to test, although you can impersonate a user with the intended Audience in another session to make testing a bit easier.

The ServiceNow developer community has been hard at work delivering content and enablement for UI Builder. At the moment, I can only recommend that you invest the time to explore the available content, leverage the collective community for advice and support (as this amazing community has done for decades now), and build up your capabilities and comfort level with UI Builder. Additionally, a light touch is the best solution and I recommend modifications in the Workspace only as a last resort, using Page Variants where possible, and with very comprehensive documentation. In the meantime, keep open communication with ServiceNow’s product managers, who are very active and open to dialog, with the intent of working collaboratively to ensure the platform continues to work for all of us.

Challenge 4: Capability Gaps

New Workspaces are introduced quickly in response to an ever-changing environment. As a result, sometimes the functionality they are meant to replace is not completely covered in the first release. ServiceNow has adopted an agile approach to this challenge, with frequent store releases occurring outside of the Major Family Release schedule aimed at providing evolving capabilities at a faster pace.

As an example, consider the evolution of the Project Workspace. When it was first released, it was limited to the new Planning Console and lacked the “Details” page to allow users to see the complete Project record; the other navigation options still linked out to the “classic” project workspace. Over the course of several Store releases, the “Classic” pages were added to the new Workspace, and as of Xanadu if you do a fresh install then the “Classic” navigation is now gone completely. There remain, as of this writing, several functions that elude the new Workspace, such as adding Test Phases to the Project from the Planning Console and preventing Child Tasks from being added to an Agile Phase.

The best way to mitigate this challenge is to carefully plan your adoption strategy. Establish a minimum capability threshold below which you cannot adopt a Workspace and then monitor the road map and releases to know when that threshold is reached. You can also identify which pieces of functionality it may still be possible to access outside of the Workspace (or is there is a way to embed it into a tab or modal, is that an option?) and explore a hybrid and phased approach to adoption. ServiceNow does a good job of regularly adding capabilities to the Workspaces, so it is likely only a matter of time until you reach critical mass and can begin adopting.

The Path Forward

Although I spent more time focusing on the challenges posed by Workspaces, my intent is not to cause despair. Having spent time working within these experiences, looking at the constant growth the steady stream of super impressive capabilities, and the simple fact that they are not going anywhere, I am hopeful that Workspaces and the tools underlying them will continue to evolve and fulfill the ServiceNow mission of making it as easy as possible to “enable regular people to create meaningful applications to route work through an enterprise.”

The power of the Now Platform lies within its community. That includes not only the users, administrators, and developers that use the platform to carry out their mission, but the folks at ServiceNow that enable those users, administrators, and developers by listening to their needs and producing a product that is unmatched in its ability to empower and inspire every day. My hope is that we continue to collaborate to make it as easy as possible to create and deliver value from this amazing platform.