UNIT III: CLIENT SCRIPTS & CLIENT GLIDE APIS-BEST PRACTICES

Client-side scripting & policies (UI and Data)

In ServiceNow, client-side scripting is essential for building interactive and user-friendly

interfaces, as well as ensuring the proper handling of data in applications. ServiceNow supports
client-side scripting through UI Scripts, Client Scripts, and UI Policies, which all play
important roles in managing the user interface (UI) and data in applications.

Here's how Client-side scripting & policies (UI and Data) are implemented in ServiceNow:

1. Client-Side Scripting in ServiceNow

ServiceNow provides several types of client-side scripts to control the behavior and interactivity
of the UI:

 Client Scripts: Client Scripts are scripts that run on the user’s browser, allowing you to
interact with fields, forms, and UI elements dynamically. These scripts can be triggered
by form events such as onLoad, onChange, onSubmit, and onCellEdit. They are
written in JavaScript and provide functionality like field validation, setting field values,
or showing/hiding fields based on certain conditions.

Examples of Client Scripts in ServiceNow:

o onLoad: Runs when the form is loaded. Often used to set default values or apply
styling.
o onChange: Runs when a field value is changed. Commonly used for real-time
field validation or to dynamically update other fields.
o onSubmit: Runs when the form is submitted. Can be used for client-side
validation before submitting to the server.
o onCellEdit: Used in record lists (e.g., in a report or list view) to execute actions
when a cell value is changed.
 UI Scripts: UI Scripts are custom JavaScript libraries that can be included in
ServiceNow to add reusable functionality that can be used across multiple UI Scripts or
Client Scripts. They are helpful when you need to write code that should be shared across
multiple scripts or when you want to centralize logic for better maintainability.
 UI Actions: UI Actions are scripts triggered by user actions like clicking a button or
selecting a menu item. They often interact with the UI and data, providing users with
custom actions like opening new forms, triggering workflows, or calling other processes.
UI Actions can run both client-side and server-side code, and it's common to see a mix of
both in a single UI Action.
 UI Templates: These allow developers to create reusable UI elements and components
for consistent use across forms or pages.

2. UI Policies in ServiceNow
UI Policies allow you to define conditions and actions for the user interface without the need for
scripting. They are typically used for things like:

 Making Fields Mandatory or Read-Only: You can use UI Policies to control when
fields should be mandatory or read-only based on certain conditions (e.g., making a
"Priority" field mandatory when "Category" is set to "Incident").
 Hiding/Showing Fields: You can conditionally hide or show fields to streamline the
form and ensure that only relevant information is presented to the user.
 UI Policy Actions: These are actions that you define within a UI Policy to set the
behavior of fields (like mandatory, visible, or read-only) when certain conditions are met.

UI Policies work purely on the client-side, and while they don't require scripting, they can
significantly enhance the user experience by ensuring data is captured correctly or providing
dynamic field behaviors based on context.

3. Data Policies in ServiceNow

Data Policies are similar to UI Policies, but they govern the data itself, typically focusing on
data integrity and ensuring that the data is valid before it is saved to the database. Unlike UI
Policies, Data Policies apply to both client-side and server-side operations.

 Field Validation: You can set up Data Policies to ensure fields meet certain criteria (e.g.,
ensuring that a phone number is in the correct format before it’s saved).
 Mandatory Fields: Data Policies can enforce whether a field is mandatory based on
specific conditions (similar to UI Policies but at the data level).
 Conditionally Enforcing Rules: You can enforce rules on fields like ensuring that a
"Location" field must be populated when a "Category" is set to "Hardware," for example.

Unlike UI Policies, Data Policies are intended to handle business rules and ensure data integrity,
ensuring that the rules apply regardless of whether the data is coming from a client script or an
API.

4. Interaction Between Client-Side Scripting and Policies

 Client Scripts and UI Policies: Client Scripts can interact with UI Policies. For example,
a client script might modify a field’s value or trigger some behavior that causes a UI
Policy to be applied (e.g., making a field read-only or mandatory based on dynamic
conditions).
 Client Scripts and Data Policies: While Data Policies primarily run on the server side,
client scripts can trigger them by invoking the necessary conditions or ensuring that the
right data is sent to the server. If a client script sends invalid data or misses a required
field, the Data Policy can reject it before it's saved to the database.

Best Practices for Client-Side Scripting & Policies in ServiceNow:

  Minimize Client-Side Processing: While client-side scripting improves user experience,
too many client-side processes can negatively impact performance. Only use client-side
scripts where necessary and avoid redundant scripts.
 Leverage UI Policies for Simplicity: Whenever possible, use UI Policies instead of
Client Scripts for simple show/hide or mandatory/read-only field logic. UI Policies are
easier to maintain and less prone to errors.
 Avoid Over-Reliance on Client-Side Validation: Client-side validation should never be
the only validation. Always pair it with server-side validation (through Business Rules or
Data Policies) to ensure that invalid data doesn't get through.
 Use Data Policies for Data Integrity: Use Data Policies to enforce business rules for
data, as they work both on the client and server sides and ensure data consistency before
records are saved.

By understanding how Client Scripts, UI Policies, and Data Policies interact and their roles in
managing both UI and data in ServiceNow, you can create a smooth, efficient, and secure
experience for users.

Modularize programming using UI Actions (both Server and Client Side) in

servicenow :

In ServiceNow, UI Actions are powerful tools that allow you to create buttons, context menu
items, and links that perform specific actions on records. UI Actions can be executed on both the
server-side (using Business Logic and server-side scripting) and the client-side (using UI
Script or client-side logic). Modularizing your programming using UI Actions allows for better
code reusability, organization, and maintainability.

Here’s how you can modularize your programming using UI Actions in ServiceNow, both on
the server-side and client-side:

1. Overview of UI Actions

 UI Actions are typically used to create custom buttons or links on forms or lists.
 They can execute actions based on user interaction (like clicking a button or selecting a menu
option).
 UI Actions are usually associated with a table and can trigger scripts to perform operations such
as record updates, invoking workflows, sending notifications, or even opening other forms.

2. Modularizing Server-Side Logic with UI Actions

Server-side UI Actions allow you to encapsulate logic on the server side and trigger processes or
database operations.
Example of Server-Side UI Action:

Let's say you want a "Close Incident" button that should update the Incident record when
clicked, changing its state to "Closed".

Steps for creating a Server-Side UI Action:

1. Create the UI Action:

o Go to the UI Actions table: System Definition > UI Actions.
o Click on New to create a new UI Action.
o Set the Table field to Incident (or any other relevant table).
o Name the UI Action (e.g., Close Incident).
o Set Action type to Form button (or List button, depending on where it will
appear).
o Set the Condition to a script or condition that checks when the button should be visible
(e.g., when the state is not already closed).

2. Server-Side Script: In the Script field of the UI Action, write your server-side script to
perform the necessary operations when the button is clicked. This could include updating
the record, calling workflows, or performing business logic.

Modularization: To keep this script modular, consider moving complex or reusable logic
into Script Includes. For example, if you have common logic for updating incident states
across multiple actions, you can create a Script Include to encapsulate this functionality.

Script Include (Reusable Code): Let’s modularize the script by creating a Script Include
that handles the logic of closing incidents.

3. Modularizing Client-Side Logic with UI Actions

Client-side UI Actions allow you to create buttons or actions that perform operations on the
client side, such as opening forms, showing popups, or manipulating UI elements without
needing to reload the page.

Example of Client-Side UI Action:

Let’s say you want to add a button to the Incident form that shows an alert when clicked.

Steps for creating a Client-Side UI Action:

1. Create the UI Action:

o Go to UI Actions and create a new UI Action.
o Set the Table to Incident.
o Name the UI Action (e.g., Show Alert).
o Set Action Type to Form button.
o Set Client to True to specify that it’s client-side.
 2. Client-Side Script: Write the client-side script for the UI Action. In this example, we’ll
show an alert when the button is clicked.
3. Modularization:

 If the client-side script is complex or reusable, consider moving the logic into a UI
Script.
 For example, you can create a UI Script (e.g., IncidentFormUtils) that contains
common functions for working with Incident forms, such as showing alerts, validating
fields, or populating dropdowns.

Script Include in servicenow :

A Script Include in ServiceNow is a reusable JavaScript file that contains server-side code designed to be
called from other server-side scripts, like Business Rules, UI Actions, Scheduled Jobs, and other Script
Includes. It's similar to creating a class or library in programming languages, allowing you to write
modular, reusable code to improve maintainability and reduce redundancy.

Key Points about Script Includes in ServiceNow:

 Server-Side Logic: Script Includes are executed on the server side and are not directly accessible
from the client (i.e., from the browser). They provide functionality to other scripts in the
platform.
 Reusability: They help encapsulate and organize logic so that it can be reused across multiple
scripts.
 Global or Scoped: Script Includes can either be global (available to all applications) or scoped
(available only within a specific application).
 Asynchronous or Synchronous: Script Includes can be written to support either synchronous
(blocking) or asynchronous (non-blocking) behavior.

When to Use a Script Include:

 When you have common logic that needs to be reused across different scripts (e.g., business
rules, UI actions).
 To keep your code modular and maintainable.
 To interact with ServiceNow's Glide API and perform operations on data or system
configurations.

How to Create and Use a Script Include:

1. Creating a Script Include

 Navigate to System Definition > Script Includes in the ServiceNow application.

 Click on New to create a new Script Include.
 Fill out the following fields:
o Name: A unique name for the Script Include (e.g., IncidentUtils).
o API Name: This is the same as the Name but used programmatically.
 o Application: Choose the application (use Global for global access or a scoped app if
you're working within a scoped application).
o Active: Set to True to make the Script Include active.
o Client Callable: Check this if you want the Script Include to be callable from the client-
side (via GlideAjax).
o Script: This is where you write your code.

2. Calling the Script Include (Server-Side)

To call a Script Include in server-side scripts (like Business Rules or UI Actions), you
instantiate the class and then call its methods.

3. Calling the Script Include (Client-Side via GlideAjax)

To call a Script Include from the client side, you use GlideAjax. This allows you to execute
server-side methods from client scripts.

4. Best Practices for Script Includes:

 Modularity: Keep your Script Includes small and focused on specific tasks. One class should
ideally handle one aspect of logic (e.g., Incident management, User management).
 Naming Convention: Name your Script Includes clearly (e.g., IncidentUtils, UserHelper),
and consider naming methods to match their purpose.
 Avoid Client-Side Logic: Script Includes should be used primarily for server-side logic. If client-
side logic is needed, use UI Scripts or Client Scripts.
 Error Handling: Always include error handling and logging (using gs.error() or gs.info())
to help with debugging and monitoring.
 Security Considerations: Be mindful of who can access your Script Includes, especially if you're
making them client-callable. Use proper validation to avoid unauthorized access.