Mastering ServiceNow Scripting

ServiceNow instances are complex. There are a great many ways in which they can be changed, and often, there are several ways to achieve the same goal using different techniques. These changes can be done through configuration and customization.

Configuration uses the ServiceNow interface to set up rules, conditions, and other configurations, like global system properties and filters. This is often made by using a series of drop-down lists.

We can see an example of this in a business rule as follows:

Figure 1.1: Configuration example from a business rule

In Figure 1.1 we can see filter conditions and and the values to set based on the filter. This configuration example uses no code and is preferable to customization. This type of filtering is seen across the ServiceNow platform.

Most system administrators will be able to administer their instance with configuration alone. A configured instance will suffice for a certain level of functionality on an instance, and, if you are trying to achieve a goal where configuration is available, it is usually the best option.

Customization is when an administrator uses scripts to allow an instance to perform further tasks beyond what configuration can do alone. ServiceNow is extremely open-ended, and the ability to write scripts at multiple points when loading and submitting forms makes it very versatile.

A customization might be to write a script to add a date validation on a field and show a message or clear the field if an incorrect value is entered. Custom scripts are to be managed by the creator, as ServiceNow is not responsible for the code. Therefore, if you start to move into the customization route, make sure you know what you are doing.

As the creator will need to maintain the script created, they will also need to ensure that it will still function when an instance of ServiceNow is upgraded.

For new administrators, it can be difficult to know when to script. For coders, it can be easy to look to script before you need to, with so many opportunities to write script in ServiceNow. However, it is much better to not write script wherever possible.

If you can configure instead of scripting, it should be your first thought. This allows the tool to be used in the way it was intended and will leave you much more prepared when upgrading your instance. Not only that; one of the main reasons for using configurations over customizing is for maintenance. Configurations are easily maintained by different admins, while customization's require some basic knowledge of scripts and the logic behind them, so they tend to be harder to maintain and troubleshoot. Remember, once you start to customize, maintaining that customiszation is your responsibility. 

If you find yourself unable to achieve your goals with configuration alone, then you should look to script. Even though configuration is your best option, scripting accounts for a lot of advanced functionality on most instances. Almost all mature instances will have some level of scripting done to them, but the instances that function better are the ones where scripting was performed when appropriate.

For example, if you are looking to show, hide, or make mandatory or read-only a field, then this could be done as a client script or a UI policy. If you simply needed to perform one of the actions based on a value in a field, then in this instance, a UI policy is the better choice, as it can achieve the goal without using a script. However, if you needed to perform the action based on whether the logged-in user has a particular role, then you will need to use a script. Scripting can be done in a UI policy, but I usually opt for a client script in this scenario.

There are a multitude of different scripts you can write in ServiceNow, and the times at which they run will often dictate which is best. However, all of these scripts will fall under two categories. These are client-side scripts and server-side scripts.

These two script types will be explored further in subsequent chapters, but we will look at the basic definitions here:

The following table shows the most common types of scripts and whether they run on the client or server side:

You may notice from the preceding table that UI Actions appear in both the client and server side. This is because they can be run as either, and therefore, they fit into both categories. We'll discuss this and the other common script types more in later chapters.

All of the script types in the preceding table will be looked at in further detail later on, and each has an important role to play in making the most of your ServiceNow instance.

Server-side scripts are considered preferable where possible, as they can run in the background away from the user, whereas client-side scripts run in front of the user and often cause the most delay in loading pages.

It is possible for client-side scripts to call server-side scripts. This will usually result in a slight delay as the information is gathered from the database. This type of server call from a client script is best avoided where possible, but often, it is necessary. Later on, we'll discuss how to best call a server-side script from the client without creating long delays for the user.

Client- and server-side scripts are a huge part of ServiceNow scripting, and the ways you can manipulate both to your advantage will determine your overall success in scripting in ServiceNow.

The order that a script executes in ServiceNow can be extremely important. Subsequent running scripts can undo or alter the changes a previous script has made.

Some scripts can be ordered by administrators, while others cannot. It is important to know how ordering your script will affect the outcome of the script. For a script that cannot be ordered it will need to run in any order compared with other baseline or custom scripts and still function correctly.

When scripts can be ordered, they are run based on the order number assigned to them. Scripts are run in ascending order, so a script of order 50 would run before a script of order 100. Each number is not unique, though, so you are able to have multiple scripts run at order 100, which is the default for a new script. In this scenario, with scripts with the same order number, you cannot be certain which order they will run in.

Consider a scenario where script A is already in existence. Let's say that script A sets a user's active field to true. As an administrator, I write script B to set a user's active field to false. If script B has a lower order than script A, it will have no effect. This can easily be misinterpreted as script B not working correctly, but it is just being overwritten by script A. If script B is at a higher order than script A, then script B will look to be working correctly. However, script A is then redundant. 

It isn't often that two scripts fly so obviously in the face of each other, but hidden among other code and multiple scripts, the above scenario is quite common in a more complicated guise. Ordering is therefore very important and quite a common reason for problems with scripts. To ensure you do not have issues with ordering in scripts, ensure you are aware of other scripts running on the field or fields you are working with before making changes with your own script.

As stated earlier, sometimes, you cannot order scripts. An example of this is for client scripts. These will essentially run in a random order, and therefore, when writing them, an administrator will need to take this into account. This means you cannot write a client script that relies on values or fields from another client script, otherwise it may break (if execution is not in the order you had hoped).

Most server-side code can be ordered, however. The order in which server-side scripts are run can be seen in the following diagram:

Figure 1.2: Execution order of scripts

As you can see in the preceding figure, there are a number of different times at which scripts are run, and therefore, it is important for an administrator to determine the right order for their script.

There are two significant points to note from this ordering system. The first is that, barring email notifications, a script can be called before or after the database operation. Selecting the right script execution timing can help streamline an instance. Selecting the wrong execution time will usually not cause a problem, but can be rather inefficient. Generally, it is a best practice to call a script before the database operation if the script will change values about the current record; otherwise, the script can be run after the database operation.

The second significant point is that order 1000 is an important number in ServiceNow. When I first started using ServiceNow, I wondered why so many scripts were ordered with such a high number. The reason is to run scripts in front of or behind engines. These engines include SLA, approval, and workflow engines. The main reason I have come across in my experience is to order scripts in relation to workflow scripts.

Script execution order bugs can be difficult to diagnose, as it can take a long time finding what other scripts are interfering with the current script you are working on. That is why it is important to label all code clearly and write meaningful comments within your scripts.

ServiceNow uses JavaScript as a language for the majority of the scripts you can write or edit. If you already have a background in JavaScript, then you will certainly have a head start when it comes to writing your first scripts. The JavaScript engine used for writing scripts is updated as new versions of ServiceNow are released. The other language used is called Jelly. Not many people outside of the ServiceNow space are aware of Jelly, and it certainly wasn't a language I was familiar with before working with ServiceNow. Fortunately, Jelly is not used in the majority of scripts, and we'll cover how and where to use it in a later chapter.

Before you start writing your first script, it is important to check whether your goal can be achieved without using script. This should always be a consideration before you get started. By leveraging configurations in the form of UI policies, for example, it is possible to avoid customization all together.  

When scripting, it is important to think about what you want to achieve, and which records and what fields in the database you will need access to. The most common scripts will simply need information from the current record being displayed or updated, but more complex scripts may need to access data from several different tables. It is a good practice to ensure that the database and table structure will allow you to get all the data you need for your script from the current record before you start.

One other point to note when scripting is to make sure your code is well documented, including good comments and descriptions of what goals are to be achieved. While you are writing code, it can seem that what it does will be obvious, but coming back to the same code after some time, that often will not be the case. Maintaining ServiceNow instances is a big part of an administrator's job, and trying to do this with no comments in scripts can be a laborious task. I have come across many instances with insufficient comments and descriptions, and a lot of time is initially wasted on discovering how it all hangs together. Documenting your code will not only help you over time, but will also help any other administrators who need to maintain your scripts and instances.

For example, it is important to explain what each function does:

/*This function returns true or false based on the whether the input variable is 0
Inputs: input - integer
*/
function myFunction(input) {
if (input == 0) {  
  return true;
} else {
  return false;
}
}

Most scripts will use the glide classes provided by ServiceNow, which we will discuss in the next chapter.

When you encounter a script field in ServiceNow, it will have some additional features that allow you to create your scripts with greater ease than you would in a simple text field. This type of field is named a script type and is found throughout ServiceNow.

We will now look at this field type in detail so you can use this field to its best and understand the capabilities it has. First, let's take a look at this field in Figure 1.2:

Figure 1.3: Script type field

There are a number of buttons above the field that you can use to your advantage. Let's take a look at these buttons in order, as each can assist with the code we write:

Some developers will have their own external scripting tools that they use to create the script and then paste it into script fields once complete. If doing this, ensure you have the latest version of the code in your external tool so that you do not overwrite updates from others by mistake.

This gives an overview of this type of field, and it makes scripting much easier. The syntax checking and code formatting are especially helpful tools.

In this chapter, we looked at the configuration and customization of a ServiceNow instance, and when it is appropriate to use both. We also introduced the two script types: client- and server-side scripts. This chapter also explained the running order of scripts in ServiceNow, the importance of order 1000, and how this can affect script outcomes. We introduced preparing to script, with some considerations before starting; finally, we looked at the script editor. 

In the next chapter, we will look at the ServiceNow glide class. This will show you the script ServiceNow provides you, which can be used to complement your JavaScript. The glide class is a frequently used aspect of ServiceNow scripting, and understanding its use will allow you to write helpful basic scripts and serve as a great first step into writing more advanced code.