Scripts
Scripts in ServiceNow fall into two categories:
•Client-side
•Server-side
Client Scripts
Client scripts allow the system to run JavaScript on the client
(web browser) when client-based events occur, such as when a
form loads, after form submission, or when a field changes value.
• Use client scripts to configure forms, form fields, and field
values while the user is using the form. Client scripts can:
• make fields hidden or visible
• make fields read only or writable
• make fields optional or mandatory based on the user's role
• set the value in one field based on the value in other fields
• modify the options in a choice list based on a user's role
• display messages based on a value in a field
Types of Client Scripts
There are two types of scripts
• Client Scripts
• UI Policy Scripts
A Client Script executes client-side script logic when forms are:
• Onload
• Onsubmit
• Onchange
• Oncelledit
• onLoad() — runs when the system first renders the
form and before users can enter data.
Typically, onLoad() client scripts perform client-side-
manipulation of the current form or set default record
values.
• onSubmit() — runs when a form is submitted.
Typically, onSubmit() scripts validate things on the
form and ensure that the submission makes sense.
An onSubmit() client script can cancel form submission
by returning a value of false.
• onChange() — runs when a particular field value
changes on the form. The onChange() client script must
specify these [Link]: the DHTML widget
whose value [Link]: control is not accessible
in mobile and service portal.
• oldValue: the value the widget had when the record
was [Link]: Old values aren't returned for the
HTML field type.
• newValue: the value the widget has after the change.
• isLoading: identifies whether the change occurs as
part of a form load.
• isTemplate: identifies whether the change occurs as
part of a template load.
• onCellEdit() — runs when the list editor changes a
cell value. The onCellEdit() client script must specify
these [Link]: an array of the sys_ids for all
items being edited.
• table: the table of the items being edited.
• oldValues: the old values of the cells being edited.
• newValue: the new value for the cells being edited.
• callback: a callback that continues the execution of
any other related cell edit scripts. If true is passed as a
parameter, the other scripts are executed or the change
is committed if there are no more scripts. If false is
passed as a parameter, any further scripts are not
executed and the change is not committed.
The GlideForm (g_form) Class
• The GlideForm client-side API provides methods for managing form and form fields
including methods to:
• Retrieve a field value on a form
• Hide a field
• Make a field read-only
• Write a message on a form or a field
• Add fields to a choice list
• Remove fields from a choice list
• g_form.<method name>
• alert(g_form.getValue('short_description'));
• In addition to the getValue() method, other commonly
used GlideForm methods include:
• addOption()
• clearOptions()
• addInfoMessage()
• addErrorMessage()
• showFieldMsg()
• clearMessages()
• getSections()
• getSectionName()
The GlideUser (g_user) Class
• The GlideUser API provides methods and non-method properties for
finding information about the currently logged in user and their
roles. The typical use cases are personalizing feedback to the user
and inspecting user roles. Note that client-side validation in any web
application is easily bypassed.
• The GlideUser API has properties and methods to:
• Retrieve the user's:
• First name
• Full name
• Last name
• User ID
• User name
• g_user.<method or property name>
• alert("g_user.firstName = " + g_user.firstName
+ ", \n g_user.lastName = " + g_user.lastName
+ ", \n g_user.userName = " + g_user.userName
+ ", \n g_user.userID = " + g_user.userID);
• g_user.hasRole('client_script_admin’);
• g_user.hasRoleExactly('client_script_admin');
UI Policies
Like Client Scripts, UI Policies are client-side logic that governs form
and form field behavior. Unlike Client Scripts, UI Policies do not
always require scripting.
• UI Policy Configuration
• UI Policies have two views: Default and Advanced. The fields in the
UI Policy configuration are different depending on which View is
selected. The Advanced view displays all of the configuration fields.
The Default view displays a subset of the fields.
• Table: Form (table) to which the UI Policy applies.
• Application: Identifies the scope of the UI Policy.
• Active: Controls whether or not the UI Policy is enabled.
• Short description: A short explanation of what the UI Policy does.
• Order: If multiple UI Policies exist for the same table, use the Order field to set the order of
evaluation of the UI Policy Conditions.
• Condition: The condition(s) that must be met to trigger the UI Policy logic.
• Global: If Global is selected the script applies to all views for the table. If the Global field is not
selected you must specify the view.
• View: Specifies the view to which the script applies. The View field is only visible when Global is
not selected. A script can only act on fields that are part of the selected form view. If the View field
is blank the script applies to the Default view.
• On load: When selected, the UI Policy condition field is evaluated when a form loads in addition to
when field values change. When not selected, the UI Policy Condition is evaluated only when field
values change.
• Reverse if false: Take the opposite action when the Condition field evaluates to false.
• Inherit: When selected, executes the script for forms whose table is extended from the UI Policy's
table.
UI Policy Actions
UI Policy Actions are client-side logic in a UI Policy used to set three
field attributes:
• Mandatory
• Visible
• Read only
Although you can use scripts to set these attributes using
the GlideForm (g_form) API, UI Policy Actions do NOT require scripting
to set the field attributes.
Creating UI Policy Related List Actions
Use UI Policy Related List Actions to show or hide related lists.
The Problem form has multiple related lists:
• Incidents
• Affected CIs
• Problem Tasks
• Change Requests
• Outages
• Attached Knowledge
• UI Policy scripts use the client-side API to execute script logic based on
whether the UI Policy condition tests true or false. Use UI Policy scripts to
create complex conditional checks or to take actions other than setting
field attributes (mandatory, read-only, or visible).
• The scripting fields for UI Policies are only visible in the Advanced view. To
enable the scripting fields, select the Run scripts option.
• The Execute if true script executes when the UI Policy condition tests true.
• The Execute if false script executes when the UI Policy condition tests false.
• Developers can write scripts in one or both script fields depending on the
application requirements.
• Write script logic inside the onCondition function which is automatically
inserted in the scripting fields. The onCondition() function is called by the
UI Policy at runtime.
Thank you.