ServiceNow Certification Mock Exams
Click To View Now
Welcome to the complete guide for client scripts in ServiceNow! Whether you're new to ServiceNow development or looking to brush up on your knowledge, we've got you covered in the guide below.
As a ServiceNow developer, you will often be asked to configure the functionality of a form. You may be given the requirement to automatically change the behavior of a field when a different field value changes, or to display a message to the user when certain conditions are met. These requirements, as well as many others, can be achieved using a client script. If you are just beginning your journey in ServiceNow or have never worked with client scripts before, this article provides all the information you need to familiarize yourself with client scripts. We will dive into what a client script is, when and where to use it, and other helpful tips to help developers better understand client scripts.
Client scripts are a record type in ServiceNow that allows developers to execute JavaScript in the web browser when various actions occur in the system. They are basically a way to control, via scripting, the behavior of fields on forms or lists that are presented to the end user. Client scripts have access to the client-side GlideUser (g_user) and GlideForm (g_form) classes. Both these classes are essential to working with client scripts.
The most common places developers will utilize client scripts in ServiceNow is on backend forms for tables and catalog items forms. Client scripts can also be applied to lists, but this is not as common. For example, on the Incident table, a client script could be used to make certain fields on the backend form mandatory when a change occurs to the State field’s value. There are some OOTB examples of this in ServiceNow. Another example is a client script on a catalog item that stops submission of a form when the required data is not provided by the user. Client scripts on a catalog item are known as “catalog client scripts” and are essentially the same thing as regular client scripts with a few different configuration options. There are many use cases for developers to use a client script. Some of the common ones are:
One important thing to note is the difference between a client script and a UI policy. UI policies can perform similar actions as a client script, such as making a field mandatory, visible, or read only. Although it is possible, UI policies often don’t use scripting, therefore it is best practice to use UI policies to handle the simpler client-side actions. Client scripts, on the other hand, are more powerful and should be used for more complex actions. Client scripts can also do a few things that UI policies cannot, such as executing when a record is submitted/updated and accessing a field's old value after it has changed.
Another important call out is that a client script will execute before UI policy. As a developer, make sure you are aware of this when you are configuring forms or catalog items. Let’s say you wrote a client script and somewhere in the code you are making a particular field mandatory based on some scripted condition. You go to test the form and realize it isn’t working the way you expected. Your code is correct, but the field is not showing as mandatory and you don’t understand why. This may be a situation where your client script and a UI policy have conflicting actions. If there is a UI policy setting that same field to not mandatory, then the UI policy will win out because it executes last. Be sure to understand the execution order of client scripts and UI policies to avoid these types of mistakes and save yourself from a headache trying to figure out what is causing the conflict.
Let’s take a look at how to create and configure a client script. To create a client script, navigate to System Definition > Client Scripts and click the “New” button. You will be directed to the client script form as shown below. Catalog client scripts can be created by navigating to the catalog item itself and creating a new record from the “Catalog Client Scripts” related list.
It’s always a good idea to give your client script a name that indicates what the client script actually does (e.g. Make short description mandatory). The Script field is where we will write the code that determines the functionality of the client script. Some other important fields to note here are Table, UI Type and Type. For Table, select the table you would like the client script to execute on. On a catalog client script, instead of a table you will select the catalog item or variable set that the script should apply to. For UI Type, the three options are “Desktop”, “Mobile/Service Portal”, and “All”. Pay attention to this field when configuring your client scripts. The default value is “Desktop”, and if you don’t change the default your client script will not run in the Service Portal, which is usually important for catalog client scripts. A good practice is to choose “All” unless there is a very specific use case in which you wouldn’t want to.
The Type field determines when your script will run. A helpful tip for client scripts regarding this field is not to change the Type field value once you have written code in the script. This is because the Script field auto-populates with the appropriate function/parameters based on the Type field selection. It also will not update if there is already text in the Script field. For example, you create a client script with Type = onLoad and then write a bunch of code. Later you realize it is supposed to be an onChange, and you change the Type and save. The script will not function properly. Although you changed it to the correct type, the function and parameters in the code will not update. If for whatever reason you need to change the client script type after code is written, simply copy the code somewhere (not the auto-populated part, the part you wrote), clear the Script field, select the appropriate Type and paste in the code after ServiceNow updates the Script field with the correct function.
The four types of client scripts are: onLoad, onChange, onSubmit, and onCellEdit. Each of these have their own purpose. Let’s look at each one and see how to use them.
onLoad client scripts execute when the form initially loads. These client scripts are useful for scripting field behavior when a user first navigates to a form. The example below shows the content of the Script field for an onLoad client script that executes on the Incident table. The script checks if the logged in user has a specific role, and if not, locks down the State field.
onChange client scripts execute when a field value on the form is changed. If you select type as onChange, another field called Field name becomes visible on the form. The onChange client script will execute based on the field specified in Field Name. In the following example for the Incident table, when the Category field changes to “Inquiry / Help”, the choice value “1 – High” is removed from the Impact and Urgency fields.
If you notice above, the onChange client script has several parameters. One of those parameters that can be very useful is oldValue. The oldValue parameter gives you access to the initial value of a field before it is changed. For example, if we have an onChange client script that specified Caller as the field name, when the value of Caller is changed from one user to another, oldValue will store the previous value of that field. This could be useful if you want to check when a field’s value is changed from A to B, then do something based on that. Another thing to mention about onChange client scripts is the first ‘if’ statement that is auto-populated. That statement is essentially saying, if the form is still loading or if there is no new value for the specified field, don’t do anything. This is important as it ensures your script only executes when it’s supposed to.
onSubmit client scripts execute when a form is saved/updated/submitted. These types of client scripts are useful in stopping submission of a form when the user has not provided all the appropriate information. The following example runs on the Incident table. The script is checking if the Assigned to field is empty and the State is Resolved. If these conditions are true on submission, the script makes the Assigned to field mandatory, flashes a message below the field, and stops submission.
onCellEdit is a less common type of client script as compared to the other three. This type behaves differently as it applies to the list view, not the form. Like onChange, when selecting the client script Type of OnCellEdit, and new field called Field name will become visible on the form. Also, like onChange, the field specified will determine when the script will run. However, as mentioned previously it will execute when a change is made on the list view instead of the form. It is important to mention that onCellEdit client scripts are not a form of security. If you have a requirement is to prevent users from updating the data anywhere on the platform, then you should use Access Controls or some other appropriate security method to accomplish this. In our example below, we want to prevent non-Admin users from updating the Assignment group field in list view for the Incident table.
Understanding and working with client scripts is an essential skill to have throughout your journey as a ServiceNow developer. Our goal for this article was to provide you with enough information to get started. We have discussed a few examples of how to use client scripts. There are many more use cases and advanced topics to explore relating to client scripts, such as DOM Manipulation and GlideAjax. As always, we encourage you to expand your knowledge. Happy coding!
