User Interface Policies and Client Scripts

In ServiceNow, a form is not just a static page of input boxes. Every time you open a record — like an incident, a change request, or a user profile — a series of instructions run in your web browser that decide what you see and how you can interact with it. These instructions are called UI Policies and Client Scripts, and they run on the client side. 'Client side' means inside your browser, on your own computer, not on ServiceNow's cloud servers. This is important because client-side actions feel instant — there is no round trip waiting for the server to respond.

A UI Policy is a declarative rule. 'Declarative' means you tell ServiceNow what should happen without writing complex programming logic: for example, 'if the Category field is set to Network, then make the Subcategory field mandatory and visible'. The UI Policy consists of one or more conditions (if/then statements) and one or more actions (make field mandatory, make field visible, make field read-only). When a user changes a field on the form, the UI Policy engine re-evaluates those conditions immediately. If the conditions are met, the specified actions are applied. If the conditions are no longer met, the actions are reversed. UI Policies are the easiest way to make a form dynamic without writing any code, and they are the preferred method for simple conditional behaviours.

A Client Script, on the other hand, is actual JavaScript code that you write to perform more complex or custom behaviour that a UI Policy cannot handle. JavaScript is the programming language that runs in web browsers. Client Scripts can do many things: validate that a date range makes sense, auto-populate a field based on the user's location, show a warning message, or calculate a total. There are several types of Client Script, each designed to run at a different moment in the form's lifecycle:

Why do both technologies exist? UI Policies are simpler and require no coding, making them safer for administrators who are not developers. However, UI Policies are limited: they can only do what the declarative actions allow. They cannot, for example, check if a date is more than 30 days in the past, or concatenate two fields together. Client Scripts do not have those limitations because you can write any custom validation logic in JavaScript. The cost is that Client Scripts require programming skill, and a badly written Client Script can make a form slow or cause errors.

A common real-world example: imagine an IT help desk form for requesting a new laptop. A UI Policy could make the 'Laptop Model' field mandatory only when the request type is 'New Hardware'. That is a simple condition. A Client Script could then check that the user's manager is not the same person as the requester — something a UI Policy cannot evaluate because it involves comparing two field values. The Client Script runs onSubmit and, if the manager is the same as the requester, shows an error message and prevents the save.

The order of execution matters. When a form loads, onLoad Client Scripts run first, then UI Policies are evaluated. When a field changes, the onChange Client Script runs, then UI Policies are re-evaluated. When the user clicks Save, the onSubmit Client Script runs first, and only if it returns true (meaning all validations passed) does the form submit to the server. This order is critical because if an onLoad script hides a field, a UI Policy might try to make it mandatory, causing confusion. Developers must think about the sequence to avoid conflicts.

For the SNOW-CAD exam, you need to know which tool to use for a given requirement. Use a UI Policy when the requirement is simple, condition-based, and involves only making fields mandatory, visible, or read-only. Use a Client Script when you need custom logic, complex calculations, or validation that compares multiple fields together. The exam will present scenarios and ask you to choose the correct implementation.

Imagine you work as a ServiceNow administrator for a mid-sized company that uses the platform to manage IT support requests. The service desk team receives dozens of incident tickets every day, and they need a way to ensure that each ticket contains all the necessary information before it gets assigned to a technician. Currently, agents spend too much time calling users back to ask for missing details, which delays resolution times. Your manager asks you to improve the incident form so that the required information is enforced at the point of entry — when the user submits the ticket through the self-service portal.

You start by identifying the fields that are commonly left blank: the 'Category' field, the 'Short Description', and the 'Contact Type' (phone, email, walk-in). Your first step is to create a UI Policy on the incident form. You set the condition to 'Always' — meaning this policy applies to every new incident. You then configure three actions: set 'Category' to mandatory, set 'Short Description' to mandatory, and set 'Contact Type' to mandatory. That is it. No code needed. The next time a user tries to submit a ticket with an empty Category, the form will highlight the field in red and prevent submission. This solves the most basic problem.

But you notice a more subtle issue. When a user selects 'Email' as the Contact Type, agents expect an email address to be filled in, not a phone number. A UI Policy can handle this too: you add a condition that says 'Contact Type is Email'. Under that condition, you set the 'Email Address' field to mandatory and the 'Phone Number' field to hidden. When the user switches Contact Type to 'Phone', the opposite happens. This is a perfect use for UI Policy because it is a simple if-then rule about visibility and requirement.

Now, your manager reports another problem: users sometimes enter a 'Short Description' that is shorter than 10 characters, which is not useful for diagnosing the issue. A UI Policy cannot check character count — it can only make a field mandatory or visible. You need a Client Script for this. You create an onSubmit Client Script on the incident form. The script runs JavaScript code that reads the length of the 'Short Description' field. If the length is less than 10, the script displays an error message saying 'Please provide a more detailed description (at least 10 characters)' and returns false, which cancels the save. The user stays on the form and can fix the problem.

Later, you want to automatically set the 'Assignment Group' based on the selected Category. For example, if the Category is 'Network', the script should set the Assignment Group to 'Network Team'. This cannot be done with a UI Policy alone because setting a field's value is not an action available in UI Policies. You write an onChange Client Script on the 'Category' field. When the Category changes, the script checks the new value and uses a simple if-else to set the 'Assignment Group' field automatically. This saves the user from having to search for the correct group in a long list.

Over the next few weeks, you continue to refine the form. You add an onLoad Client Script that hides the 'Resolution Notes' field when the incident is new (state is 'New'), because that field should only be filled by the technician once work begins. You also add a UI Policy that makes the 'Resolution Code' field mandatory when the state changes to 'Resolved'. The combination of UI Policies for simple rules and Client Scripts for complex logic keeps the form clean, responsive, and reliable. Your service desk team reports a 40% reduction in incomplete tickets, and your manager is impressed with the improvement.