Gaurav Kamble

SERVICENOW-CLIENT SIDE VS SERVER SIDE SCRIPTING

In ServiceNow, client-side scripting and server-side scripting play distinct roles in how the platform
handles user interactions and processes data. Each has a specific function depending on where the logic
runs: either in the user's browser (client-side) or on the ServiceNow server (server-side). Below is a
detailed explanation of both:

1. Client-Side Scripting

Client-side scripts in ServiceNow run on the user's browser. These scripts are mainly responsible for the
user interface (UI) behavior, enhancing user experience, and responding to user interactions without
requiring a server call.

Use Cases of Client-Side Scripting:

• Validating form fields before submitting data to the server.

• Dynamically changing the UI, such as hiding/showing fields or sections.
• Providing real-time feedback (e.g., error messages, tooltips).
• Fetching or manipulating data in real-time without refreshing the page.

Common Types of Client-Side Scripts in ServiceNow:

1. Client Scripts:
o These are used to execute JavaScript code when forms are loaded, changed, or submitted.
o Client scripts in ServiceNow have four types:
▪ onLoad: Runs when the form loads (e.g., pre-populating fields, making fields read-only).
▪ onChange: Runs when a particular field changes (e.g., changing field behavior based on
another field’s value).
▪ onSubmit: Runs when the form is submitted (e.g., validating data before submission).
▪ onCellEdit: Runs when a cell in a list is edited.

This client script sets the value of the "state" field to "In Progress" when the form is loaded.

2. UI Policies:
o These control form fields based on conditions. They can make fields read-only, mandatory, or
hidden based on certain criteria. UI Policies are mostly declarative, but you can also add
scripting for more complex logic.
3. UI Actions:
o Client-side UI Actions can trigger client-side code when buttons, links, or context menu items
are clicked. They can include Client Script logic as part of their action.
 Gaurav Kamble
SERVICENOW-CLIENT SIDE VS SERVER SIDE SCRIPTING

Advantages of Client-Side Scripting

• Performance: Provides instant feedback to users by running in the browser, avoiding

unnecessary server calls.
• UI Responsiveness: Can manipulate UI elements, enhance the user experience, and enforce
client-side validation.

Limitations

• Security: Since client-side code runs in the browser, users can see and potentially alter the
script. Sensitive business logic should never be placed in client-side scripts.
• Browser Dependency: Client-side scripts depend on the user's browser environment, which
can sometimes lead to inconsistent behavior across different browser

2. Server-Side Scripting

Server-side scripts in ServiceNow run on the ServiceNow server. These scripts are used to interact with
the database, perform backend operations, enforce business logic, and process complex data.

Use Cases of Server-Side Scripting:

• Performing database operations (creating, updating, or querying records).

• Executing complex business logic that should remain hidden from the user.
• Automating workflows and actions that don't require direct user input.
• Triggering actions based on data changes in the backend.

Common Types of Server-Side Scripts in ServiceNow:

1. Business Rules:
o Business rules are scripts that run when records are inserted, updated, queried, or deleted. They
are triggered by database actions and run before or after the database operation.
o There are four types of business rules:
▪ before: Executes before the database operation.
▪ after: Executes after the database operation.
▪ async: Executes asynchronously after the database operation.
▪ display: Executes when a form is loaded and before data is sent to the client.

Example: This business rule sets the "impact" field to 3 whenever the "priority" field is 1.
 Gaurav Kamble
SERVICENOW-CLIENT SIDE VS SERVER SIDE SCRIPTING

2. Script Includes:
o Script Includes are reusable server-side code libraries. They are typically used to define reusable
functions that can be invoked from other scripts such as Business Rules, Workflows, or Client
Scripts (via GlideAjax).
3. Scheduled Jobs:
o These scripts run at scheduled times and are used for automating tasks like sending email
reminders or cleaning up old records.
4. Workflow Scripts:
o These are scripts that run as part of workflows in ServiceNow, allowing more complex actions
than the declarative steps within workflows.
5. UI Actions (Server-Side):
o Server-side UI Actions run on the server when a user performs an action like clicking a button.
They can perform server-side operations like database queries or updates.
6. Glide System APIs:
o Server-side scripts often interact with the Glide System API (gs object) to perform various tasks,
such as:
▪ Logging (gs.log, gs.warn).
▪ Database queries (GlideRecord).
▪ Sending emails (gs.eventQueue).

Example: This script finds all incidents with priority 1 and updates their state to 2.

Advantages of Server-Side Scripting:

• Security: Sensitive business logic and database operations are hidden from the client, reducing
the risk of tampering.
• Powerful Processing: Server-side scripts can interact directly with the database, perform
complex data manipulation, and automate backend processes.
• Consistency: Server-side scripts run in a controlled environment (the server), ensuring
consistent behavior across different clients and users.

Limitations:

• Performance: Each server-side script requires a server call, which can slow down the user's
experience if used excessively.
• UI Interactivity: Server-side scripts don’t provide real-time feedback to users unless explicitly
called by a client-side script via asynchronous calls (e.g., GlideAjax).
 Gaurav Kamble
SERVICENOW-CLIENT SIDE VS SERVER SIDE SCRIPTING

3. Client vs. Server-Side Scripting: A Comparison

Feature/Aspect Client-Side Scripting Server-Side Scripting

Execution Location User's browser (client) ServiceNow server
Enhancing UI, validating form inputs, Business logic, database operations,
Primary Use
dynamic updates automation
Example Client Scripts, UI Policies, UI Actions Business Rules, Script Includes, Glide
Components (client) APIs, UI Actions (server)
Performance Real-time feedback, fast response Slower due to server communication
Security Less secure; scripts visible to users More secure; logic hidden from users
Hiding/showing fields, validating form Updating records, complex business
Use Case Example
data logic execution
Requires server calls for database Direct access to the database and server
Communication
interactions (via GlideAjax) resources

Conclusion

• Client-side scripting is best for enhancing the user interface and handling real-time
interactions without frequent server calls.
• Server-side scripting is best for performing secure, complex operations on the database or
business logic.

In ServiceNow development, you often need a combination of both client and server-side scripting to
create a seamless user experience while maintaining robust backend functionality.