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.