Will Service Portal survive the NOW Experience Framework?

Introduction

If you’re a ServiceNow developer, there is a high chance that you have already heard about the Now Experience Design System and UI Framework released this year in the Orlando version. Since then, I've seen many developers, customers and partners asking the same questions:

"Is Service Portal dead?"

"Can we use these Now components in the Service Portal?"

"What is this framework based on?"

"Should we start migrating from Service Portal to Agent Workspace?"

"Why do we need to learn a new framework?"

The goal of this article is to provide answers to these questions and give you a better picture of the benefits coming in ServiceNow web development’s future.

Why did ServiceNow launch the Now Experience Framework?

First, we should start by asking ourselves why anyone would actually bring a totally new framework into development. We’ve seen this before, right? We were using the good old macros with Jelly to build a customized portal experience built on top of CMS (Content Management System). After that, we adopted Service Portals (SP) with the underlying AngularJS library.

It all looked promising, new, and fancy until you started to realize that there is a huge technical debt bubbling inside the platform. Everything that worked previously in the native platform (incident deflection, form client scripts, order guides, etc.) suddenly stopped working in SP, and we either had to wait for a new version to bring those features back or implement it by ourselves. This brought more and more disparities between different UIs in the platform and still brings unnecessary overhead when you want to build something. Do you want to create a customized catalog variable and still support the platform view and SP as well? Well, you need to code it in 2 totally different tech stacks.

When ServiceNow introduced new capabilities for knowledge management, such as versioning and knowledge blocks, they all worked fine within the old UI but not in the SP. But again we had to wait. And with the official abandonment of the AngularJS framework, ServiceNow quickly realized that we need to rethink how we deal with the platform UI globally. So more difficult questions arose like:

What kind of fancy new framework shall we use?

How are we going to continue supporting the customisations that customers need?

How can we ensure that the framework we choose will not be abandoned in the coming months?

And the answer to these questions is the Now® Experience UI Framework, which should hopefully unify the whole platform UI, speed up the development process and ensure that it will last much longer than AngularJS or Jelly. How can we be so sure? Well, the reason is simple. The UI Framework no longer depends on a third-party framework, but instead relies on a set of web standards like custom elements, shadow DOM, slots and CustomEvents which are native to the browser. And while frameworks come and go, standards compliant HTML is very likely to last or remain popular for a long time.

Major advantages of the Now Experience Framework?

You might start asking what kind of benefits this new framework will bring. At this point there isn’t much that the Now Experience Framework will bring to you; at the time of writing, the Now components can only be officially used in predefined places inside Workspace Experience. But we can expect much more attention from Servicenow in the future, and I’d like to mention several key benefits that could lead to the end of the Service Portal.

Reusability of now components

The main selling point of developing Now components might be “Build it once and use it anywhere you want.” And by anywhere I mean not only using it within the ServiceNow platform, but in any kind of web application.

How is that even possible? Technically, the Now components are just framework-agnostic custom elements that can be seamlessly used together with different frameworks. This strengthens the promise of longer life support for the Now experience framework, and there’s no vendor lock-in to any proprietary JavaScript framework. By the way, have you noticed that the Guided Application Creator used within the Studio is built with the Now Experience Framework, while the whole Studio is an AngularJS app?

Guided Application creator

Attractiveness for frontend developers

In my nearly 5 years of experience of building with the NOW platform, I've had the opportunity to cooperate with a wide variety of people working on different kinds of projects. And every time I met a person with a strong frontend background, I quickly realized how they were struggling or becoming frustrated with the development process. And I couldn't blame them. There are some key differences compared to standard web development processes and tools.

When you say to a potential candidate that they’ll be working with the AngularJS framework, they tend to bolt for the doors in search of a more interesting job. But the Now Experience Framework is a big game-changer compared to any other development inside the platform. It requires “offline” development on a local machine which closely resembles the current web development process. And I’ve already found several colleagues eager to start developing on it. This can also bring a stronger community base that will help to grow the number of available components.

Faster to build, easier to maintain and upgrade

The main disadvantage of the OOTB Service Portal widgets is that even though they were designed to be reusable, customers always tend to end up with greater or smaller customisations, or even trying to build new ones. And the main reason for these customisations is the simple fact that they’re usually written as a big monolithic block of code that you can't easily override, change, and requires you to end up with cloning them. And every time you clone a widget, you end up being responsible for maintaining and upgrading these widgets. This requires you to review all changes made to those widgets during the upgrade phase and merge all differences. Sounds time-consuming, right? Now imagine that you no longer need to modify the big blocks of code but instead start utilizing the more granular smaller parts that will automatically get upgraded without worrying about any manual merging process. Because of a local development server, we can also incorporate some 3rd party testing frameworks like Jest, Enzyme that can ensure that our code is safe and stable.

Consistent look and feel across the platform

So far we’ve mostly discussed the underlying tech stack for platform UI. But we also shouldn't forget about the user experience provided by multiple products within the platform UI - and at the moment this is inconsistent. By user experience, we mean not only visual representation but also behavior. As an example, take a look at the Watch List field on the Incident form. In order to edit the field, you need to click on the lock icon in the Platform view, which is not very obvious for newcomers. Meanwhile, in the Service Portal, you can just start typing a name in the input field. I'll leave it up to you which one is better, but this is just a small example of many UI differences, and you can find far more examples by yourself.

Platform UI

Service portal

When you start developing applications based on the Now components, you can be sure that the application will look like it was built by ServiceNow - it uses the same components as the internal products. You don't need to worry about matching styles, shapes and patterns.

Conclusion

So is Service Portal going away soon? Should we really switch to the Workspace experience and start building Now components? Not necessarily. ServiceNow has already mentioned that they’ll still support the Service Portal in the future, but we can definitely see more development focusing on the Now Experience itself in upcoming releases. We still need to wait for an official way of interoperability between the Service Portal and Now Experience, which is a crucial point for providing a migration path from SP to the Workspace experience. We also need to have many more components publicly available for building native platform applications. At the moment we’re still missing the most crucial parts for building things like forms, lists and reports.

Another thing that might slow down the adoption of the Now Experience is the steep learning curve for development, which requires a whole new set of skills which most generic ServiceNow developers lack. And if you still need to support an older version of IE or Edge (not the Chromium-based one) you might be out of luck of switching to a new Workspace experience.

Personally, I can't wait to try the new UI builder hopefully coming in the Q release next year. It definitely looks promising, and I guess it’s just the beginning of a new era that will allow us to build great experiences for our customers. While this new UI builder is focused more on the agent/fulfiller personas, it’s just a matter of time until we get a new self service portal solution based on the Now Experience.