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:

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:

• A client-side script will run in front of the user, based on the data that was delivered to the user on the web page, usually to a form or a list, in that no form submissions are required. These scripts can only use the data loaded as part of the web page to run their scripts with (if they only run on the client side), as that is the only data available. The most common client-side script is simply named a client script in ServiceNow. Some common uses for these scripts would be to draw attention to a field to change or validate a field's value.
• A server-side script will run behind the scenes once a form is submitted or a different trigger occurs. As this type of script is run on the server, it can use all the data held in the ServiceNow database, rather than just what was loaded on the web page. The business rule is the most commonly used server-side script. A business rule has many ways of functioning, but will usually run after a form submission, with common tasks to amend field values or update parent or child records.

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:

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.