(One in a Series of Posts About Building the Right User Experience)

Introduction

User Experience (UX) is a broad topic, with people whose full-time job is designing and ensuring implementation of a good user experience. I’ve found this is a discipline only done in very large organizations, or organizations who have UX as a primary focus. This is a minority of ServiceNow implementations. UX in most ServiceNow environments is left to the best efforts of developers, admins, QA and business stakeholders. And often it is largely ignored!

Although I’ve previously written about UX in general – form administration primarily – there are specific technical solutions in ServiceNow to provide a better UX. In my experience I’ve found these solutions are often undocumented (at least officially), and therefore unknown. And yet they are key to basic, fundamental good UX.

In this post I’m going to present and describe a solution for confirming an action before taking it – allowing a user to consider their action and confirm it before the system takes the action.

The Problem

Even if you’re not familiar with UI Actions, you are. These are the ServiceNow elements that manifest themselves as buttons, right-click menu items, and form links. (“Save” and “Update” are UI Actions.) There are plenty of times that a business requirement obligates the creation of a new UI Action. Like a lot of configuration, this is fairly straightforward in ServiceNow and well known by most admins and developers. The basic configuration of a UI Action includes:

• Name (what shows to the user)
• Conditions by which it should show
• What kind of element it is (button, etc)
• Whether it runs on the client (browser) side or server side
• A script that runs upon clicking the action

The issue we’re dealing with in this article is that they do not include a modern and sensible way to confirm a user’s decision prior to execution. For many “standard” UI Actions (like Save or Update), a confirmation isn’t really needed. But in cases where you develop a new UI Action, the requirements often takes a “larger” action when executed – perhaps copying a record, recalculating a total, updating a related record, or triggering an integration. Regardless, these are consequential enough that a good UX design includes a confirmation of the action prior to taking the action. As mentioned, ServiceNow does not offer this as a configuration*, nor as part of their documentation.

* Where it is configurable and not a custom or copied code solution.

The Solution

We’ve established that good practice is to have confirmation for actions that make significant or important changes in the system. Let’s look at the components and settings of the UI Action that will make this possible with the best UX.

• Combine client and server-side script into one. This means the script portion of the UI Action will have parts that run on the client browser side – this is the confirmation, and parts that run on the server-side.
• Configure the client and server identifiers. These are the Action name and the onClick fields.
• Use an out-of-the-box UI Page as your confirmation dialog. This is the key element of the solution. While you could use a standard Javascript pop-up confirmation, these are not “business class” and can be disabled in some browsers. The ServiceNow dialog “fits” the UI better, and has more configurable elements.
• Message the user appropriately. In both the confirmation dialog and the aftermath of the action, the user should be informed what will happen if they proceed, and what did happen (even if unexpected).
• Send the user to the appropriate location. At the end of the action execution, the system will take the user to the previous screen if not directed elsewhere. In the script we will redirect the user to the place where it makes the most sense based on the action executed.

Words are nice, but let’s look at a solution example so you “get the picture”. I’m going to create a UI Action to Clone an Incident record – not a great business case, but just to get the idea how this works.

The main form elements are shown below. Most parts should be self-explanatory. Note the Action name – we’ll see this in the script. Also, we can uncheck “Show insert”. This action would not be used on new records, only existing.

Farther down, there’s the client identifier – the script function that runs when you click the Action. (If you’re wondering, the “current.canWrite()” makes the button visible to anyone who has write access to the record they’re on.)

Because the script uses some Javascript browser functions, you’ll need to uncheck the “Isolate script” box. (This may not be on the form by default; you could add it or use the list view to edit.)

I’ll show the script in several chunks and point out the important pieces.

In the first section above:

• Line 2 contains the function definition that is called from “onClick”.
• Line 3 uses the correct type of pop-up based on if the underlying screen is full screen or a window.
• Line 4 contains the name of the UI Page being used for the pop-up dialog. (There are others out-of-the-box if you check the list of UI Pages in the system.)
• Line 5 sets the title text for the dialog
• Line 6 sets if the dialog shows an informational or a warning icon
• Line 7 sets the text that appears in the pop-up dialog just above the Cancel and OK buttons
• Lines 9 and 10 are the names of the functions that get called when the Cancel and OK buttons are clicked

In the next section, the other client-side functions either cancels and closes the dialog, or submits the action to the server-side for processing:

Finally, the server-side script below executes the clone, redirects the user to the new record, and messages that the clone occurred. (Technically, line 26 is client-side and line 27 is a server-side function name, but it’s not critical to know this, just that it’s needed and works.)

Lines 31-37 can be whatever you need them to be to fulfill the action required. You can also call functions in Script Includes from here. The key UX takeaways are lines 38 and 39, which navigate and inform the user in “sensible” ways. (Again, use your best judgment for this portion as well – think about what navigation and messaging would make sense to you if you were executing the action.)

Very briefly, here’s what this looks like in action. Upon clicking “Clone” on an open Incident, you are presented with this dialog box:

If you click Cancel, the dialog box goes away and you’re back on the original Incident form. If you click OK, the system executes the server-side script, sends you to the new Incident, and provides the messaging from the script:

This provides a much better user experience than having everything executed on the server-side, and either leaving the user on the same record or sending them to the new record without any confirmation of either to take the action (and what it implies), or what just occurred.

The last thing I’ll point out is the importance of aligning your names across the UI Action fields and within the script. The image below shows the five places function and action names need to align or your UI Action will not work.

As usual, a little attention to detail goes a long way!

Conclusion

How ServiceNow is perceived, and how your work is perceived, is based on how users view their experience of using the system. While ServiceNow has provided plenty of good user experiences “out of the box”, sometimes the platform falls short in giving admins and developers the tools at hand to develop their own best-practice user experiences. But often the components exist even if they are not well known or documented. Use these components to create the best UX possible, and put what you’ve built into your library of tools to draw from as you develop similar solutions down the road. Your users will appreciate it and you’ll be a ServiceNow star!

Go forth and develop wisely…