Client scripts let you control what happens on forms in real-time — hide fields based on user selections, validate input before submission, or auto-populate related data. This guide walks you through creating each type and understanding when to use which one.
What client scripts replace
Before client scripts, form behavior was either static or required full page refreshes to change anything. Users had to fill out irrelevant fields, submit forms to find out about validation errors, and couldn't get immediate feedback on their input. The people building forms — platform developers and admins — had to choose between cluttered forms that showed every possible field or multiple form views that were hard to maintain. Business stakeholders complained about poor user experience, and support teams fielded tickets about confusing form behavior.
How client scripts control forms
Client scripts are JavaScript that runs in the user's browser, not on the ServiceNow server. This means they're fast but limited — no GlideRecord database queries, only what's already loaded on the form. There are four types: onLoad runs when the form opens, onChange fires when specific fields change, onSubmit runs when the user submits (use for validation), and onCellEdit handles list editing. Most scripts start as onChange scripts that show/hide fields, then you add onLoad to set initial states and onSubmit for final validation. The key is understanding that you're manipulating the DOM and form state, not database records.
Building production-quality client scripts
Once your basic script works, focus on performance and maintainability. Use specific field conditions instead of running logic on every form load. Extract complex logic into Script Includes and call them via GlideAjax for server-side data access. Add null checks and defensive coding since users can manipulate browser state. Consider mobile compatibility — client scripts run differently on the mobile app. The difference between a working script and a production-ready one is error handling, performance optimization, and code that other developers can modify without breaking everything else.
Before you start
- •admin role or elevated developer access
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Navigate to Client Scripts
Go to System Definition > Client Scripts. This shows all existing client scripts across your instance. You'll see the Table, Type, and Active status for each script, which helps you understand what's already running on forms you're about to modify.
Filter by your target table first to see what client scripts already exist — you might be able to modify an existing script instead of creating a new one.
Create new client script record
Click New to create a client script record. Set the Name to something descriptive like 'Hide priority when category is hardware'. Choose your Table — this determines which forms the script runs on. Set Type to onChange for field-dependent behavior, onLoad for initial form setup, onSubmit for validation, or onCellEdit for list modifications.
Start with onChange scripts since they're the most common and easiest to test.
Configure the trigger conditions
For onChange scripts, set the Field name to the specific field that triggers your script — like 'category' or 'state'. Check Active to enable the script. Set UI Type to Desktop, Mobile, or Both depending on where you need the behavior. Most scripts should target Both unless you have specific mobile considerations.
Write the script logic
In the Script field, write your JavaScript using g_form methods like g_form.setVisible(), g_form.setValue(), or g_form.setMandatory(). For onChange scripts, check the newValue parameter to determine what action to take. For onSubmit scripts, return true to allow submission or false to block it. Remember you're in the browser — no server-side GlideRecord calls.
Use g_form.addInfoMessage() to provide user feedback when your script does something non-obvious like hiding fields or changing values.
Test the script behavior
Save the client script record and open a form for your target table. Test the trigger conditions by changing field values or performing the actions that should fire your script. Check browser console for JavaScript errors. Verify the script works on both new records and existing ones, since form context can affect behavior.
Add condition and finalize
If your script should only run on certain records, add a Condition using the condition builder — like 'state is not Closed' or 'assignment_group is IT Support'. This prevents unnecessary script execution and improves performance. Set an appropriate Order value if you have multiple scripts on the same table and need them to run in sequence.
Best practices
Always check for null values before manipulating field values — users can clear fields in unexpected ways that break scripts expecting data.
Use onLoad sparingly and only set initial states — heavy onLoad scripts make forms feel slow and can cause race conditions with other scripts.
Never put database queries directly in client scripts — use GlideAjax to call server-side Script Includes when you need data that's not on the current form.
Add meaningful conditions to prevent scripts from running unnecessarily — an onChange script that runs on every record update can severely impact performance.
Test client scripts in both desktop and mobile interfaces — g_form methods behave differently on mobile and some features aren't available.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue