The ServiceNow Nerd

The musings of a ServiceNow platform developer and enthusiast

The SN Nerd

Why You Should Stop Using Alert() In Your Client Scripts NOW

by snnerd
1,931 views

In this blog, you will learn about the history of the JavaScript alert() function, the negative impact of using it, and some alternatives for the service portal, classic, and configurable workspace environments.

A window into the past


The alert() function is a method of the Window object in JavaScript, and it has been around since the early days of JavaScript. JavaScript was created in 1995 by Brendan Eich while he was at Netscape. The first version of JavaScript, initially named Mocha and later renamed to LiveScript (and eventually to JavaScript), was shipped with Netscape Navigator 2.0 in December 1995.

Given that alert() is a fundamental method for simple user interaction and debugging, it’s safe to say that it was present from the very beginning or was introduced very shortly thereafter. Thus, alert() dates back to the mid-1990s. However, to pin down the exact release version of Netscape Navigator or the exact JavaScript version that introduced alert(), one would need to delve into specific historical browser documentation from that era.

The alert() function is a straightforward means to display messages to users. In the formative years of the internet, when browsers were still in their infancy and web design principles were yet to be established, this function offered developers a quick and easy way to communicate with their audience. It was akin to a digital shout – abrupt, noticeable, and almost impossible to ignore.

Yet, as with all tales of evolution, what was once a novel tool gradually became a relic of the past. The web matured, user experience principles evolved, and the loud, interruptive nature of the alert() dialog started to feel intrusive and jarring.

Now, why should ServiceNow developers care about this bit of JavaScript history? Simple. As we adapt and use various web functionalities within the ServiceNow platform, it’s crucial to understand why some are best left unused.

Time to desert the alert

Just in case you don’t know what alert() looks like, here is an example:

The horrors of using alert

To summarise, using alert() in ServiceNow client scripts can be problematic for a few reasons:

  1. Distraction, not Interaction: ServiceNow applications aim for smooth and efficient user journeys. An unexpected alert popping up can disrupt this experience and leave users disoriented.
  2. Mismatched Aesthetics: Alert boxes have their own browser-defined look, which might not gel with the ServiceNow UI. A seamless UI is crucial for maintaining a professional appeal.
  3. Lack of Flexibility: With just an ‘OK’ button, alert() provides no room for user interaction or feedback, limiting its use cases.

A better Alert in ServiceNow

According to my own LinkedIn survey, more than half of ServiceNow developers are still using alert()! It is time to up your ServiceNow development game and use ServiceNow OOB API instead.

In this article we will use the example of a UI Policy Run Script triggered when a past date has been selected, and contrast it with the experience of just using the alert() API.

alert() in classic environment

I don’t think user experience can get any worse than this.

We can and will do better!

Let’s see how to improve this in every UI.

Classic Environment

Set the Run script in UI type to Desktop to ensure your code only runs in the classic environment. This code will not work in a Configurable Workspace.

function onCondition() {
    var hideCloseButton = true;
    var width = 600;
    var gm = new GlideModal("glide_warn", hideCloseButton, width);
    gm.setTitle("Alert");
    gm.setPreference('title', 'Start date must be in the future.');
    gm.render();
    g_form.clearValue('start_date');
}

In the example above, I have used the glide_warn UI page. Using different UI pages you can add more buttons and functionality to meet your use case. You can find the official documentation for GlideModal – Client on the Product Documentation website.

There are many more uses for GlideModal that you can read about on fellow Australian David McDonald’s fantastic blog post GlideModal usage and examples.

Using GlideModal to show an alert in the classic environment

Contrasting the GlideModal experience with the alert(), we can see that the Dialog box is still quite far from the triggering action, although not as high as it was. The background is greyed out, which helps bring attention to the alert, and If you are using NextExperience, the alert will match your instance theme quite nicely. This is much more professional.

Configurable Workspaces

Set the Run script in UI type to Mobile / Service Portal to ensure your code only runs in Configurable Workspaces. This code will throw an error when run in the classic environment.

function onCondition() {
	g_form.clearValue('start_date');
	g_modal.alert("Start date must be in the future.");
}

There are many other ways g_modal can be used beyond the humble alert. Former ServiceNow MVP turned employee Ashley Snyder does a great job documenting these in the article How to use UI Actions in Workspaces on the Workspace Center of Excellence over on the ServiceNow Community.

Using g_modal instead of alert in Service Operations Workspace

Contrasting the g_modal experience with alert(), we can see the alert is literally the centre of our attention, much closer to the action that triggered the notification. The background is greyed out, bringing even more focus to the alert. The modal also matches the theme of the instance.

Classic and Workspace

Having separate scripts for each interface results in duplication of effort for UI policy Conditions or other code that is not user interface dependent.

A condition that you might have to manage twice!

Set the Run script in UI type to All to ensure your code only runs in all user interfaces.

function onCondition() {

    snNerdAlert('Start date must be in the future.');
    g_form.clearValue('start_date');

    function snNerdAlert(msg) {
        if (typeof GlideModal != 'undefined') { // Classic UI
            var hideCloseButton = true;
            var width = 600;
            var gm = new GlideModal("glide_warn", hideCloseButton, width);
            gm.setTitle("Alert");
            gm.setPreference('title', msg);
            gm.render();
        } else if (typeof g_modal != 'undefined') { // Configurable Workspace
			g_modal.alert(msg);
		} else { // Future proofing 
			alert(msg);
		}
    }

}

You will get the appropriate alert depending on the UI you are in.

Service Portal

Set the Run script in UI type to Mobile / Service Portal to ensure your code only runs in Service Portal. This code will throw an error when run in the classic environment.

function onCondition() {
    spModal.alert("Selected date must be in the future.");
	g_form.clearValue('reboot_date');
}

The spModal API can be found on the ServiceNow Product Documentation website, which can be extended as required to delight your end users.

This image has an empty alt attribute; its file name is image-13-1024x594.png
spModal in Service Portal

Contrasting the spModal experience with the alert(), we can see that the Dialog box is still quite far from the triggering action, although not as high as it was. The background is greyed out, which helps bring attention to the alert, and If you are using NextExperience, the alert will match your portals theme quite nicely. This is much more professional.

The upside of alert?

Is there any benefit to using alert() ?

Well, it will work in client scripts from any user interface.

That is the only upside, really. It is so poorly implemented and designed, that I ponder if it was ever designed to be used to alert end users. It was probably only ever intended as a debugging tool that got misused by developers (and advertisers).

Wouldn’t it be nice if there was a single, consistent, modern ServiceNow API call that worked in user interfaces? Or even better – a codeless configuration mechanism for all interfaces? For now, we just have Sensitive handling notes, but this does not handle enough use cases to be used as a comprehensive solution.

Related Posts

Leave a Comment

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More