Catalog items need client-side behavior just like regular forms — hiding fields based on selections, validating input before submission, or auto-populating values. This guide walks you through attaching client scripts directly to catalog items where they belong.
Why catalog items need their own client scripts
Regular forms use the Client Scripts module to attach JavaScript that runs in the browser. Catalog items can't use that approach — they're not traditional forms, they're dynamically generated based on variables you define. Without client-side scripts, users get static forms that can't react to their input. You end up with catalog items that accept invalid combinations, show irrelevant fields, or force users to fill out everything manually when half the fields could populate automatically based on earlier selections.
How catalog client scripts work
Catalog client scripts attach directly to the catalog item record via a related list, not through the global Client Scripts module. They use the same g_form API you know from regular forms, but reference catalog variable names (the field names you set) instead of table field names. You have two main types: onLoad scripts that run when the form appears, and onChange scripts that fire when specific variables change. The progression is straightforward — start with basic field manipulation, then add validation logic, then build complex conditional flows between variables.
Building production-quality catalog scripts
Basic catalog scripts get fields showing and hiding correctly. Production-quality scripts handle edge cases: clearing dependent fields when parent selections change, preserving user input during dynamic updates, and providing clear error messages for validation failures. Add client-side performance by avoiding unnecessary DOM queries, and build maintainable code by keeping scripts focused on single responsibilities rather than monolithic functions that handle every possible interaction.
Before you start
- •catalog_admin or admin role
- •Existing catalog item with variables defined
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 your catalog item
Go to Service Catalog > Catalog Definitions > Maintain Items and open the catalog item you want to add scripts to. You need the item record open to access the Catalog Client Scripts related list.
Open the client scripts tab
Scroll down to the Catalog Client Scripts related list and click New. This creates a script attached specifically to this catalog item, separate from the global Client Scripts module that handles regular forms.
Set the script type and trigger
Choose onLoad if your script should run when the catalog form first appears, or onChange if it should fire when a specific variable changes. For onChange scripts, set the Variable Name field to the exact variable name (not the question text label) that should trigger the script.
Variable names are what you typed in the Name field when creating the variable — usually something like 'location' or 'software_type', not the user-facing question text.
Write your script function
In the Script field, write your JavaScript using standard g_form methods. Use g_form.setVisible(), g_form.setValue(), and g_form.setMandatory() with your catalog variable names. For onChange scripts, access the triggering field's value with g_form.getValue() and the variable name.
Test the variable references
Save the script and test your catalog item. The most common issue is referencing variable labels instead of variable names — if fields aren't responding, verify you're using the exact Name field value from your variable definitions, not the Question field text.
Set execution order if needed
If you have multiple scripts on the same catalog item, use the Order field to control which runs first. Lower numbers execute earlier. This matters when scripts depend on values set by other scripts.
Best practices
Always use catalog variable names in scripts, not the question labels — variable names survive when someone updates the user-facing text.
Clear dependent field values when parent selections change to prevent invalid combinations from reaching the backend.
Put validation logic in both client scripts and catalog item script includes — client scripts improve user experience but server-side validation prevents bad data.
Keep onChange scripts focused on single variables rather than trying to handle multiple triggers in one function — debugging becomes impossible otherwise.
Test catalog scripts in different browsers and with different user roles — catalog forms render differently than standard ServiceNow forms.
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