Client scripts let you show and hide form fields based on what users select or type, creating cleaner forms that adapt to user needs. You'll build onChange scripts that control field visibility in real-time.
Why forms need dynamic field visibility
Static forms with every possible field visible create terrible user experiences. Users see irrelevant fields, get confused about what to fill out, and submit incomplete data because they couldn't tell what was required for their specific situation. Form designers — typically system admins and developers — end up choosing between comprehensive forms that overwhelm users or simple forms that don't capture enough detail. Business stakeholders complain that either users abandon requests or submitted data is too vague to act on.
How client-side field visibility works
Client scripts run in the user's browser and can instantly show or hide fields based on form state. You'll primarily use onChange scripts that fire when users modify specific fields. ServiceNow gives you two methods: g_form.setVisible() leaves whitespace where hidden fields were, while g_form.setDisplay() removes them from the layout entirely. Both methods preserve field values — hidden fields still submit their data when the form saves. Start with simple show/hide logic based on dropdown selections, then add complexity like multiple field dependencies and cascading visibility rules.
Building production-quality visibility logic
Basic visibility scripts work but create maintenance headaches as forms evolve. Production improvements include consolidating related visibility logic into single scripts instead of scattered onChange handlers, using consistent naming conventions for fields that control visibility, and adding null checks before referencing field values. Consider whether you need setVisible or setDisplay based on your form layout — setDisplay creates a cleaner experience but can cause jarring layout shifts. For complex forms, document your visibility dependencies because the next developer won't intuitively understand why Field A controls Fields B, C, and D.
Before you start
- •admin role or sufficient ACLs to create client scripts
- •a form with fields you want to show and hide
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
Create the client script record
Navigate to System Definition > Client Scripts and click New. Set the Name field to something descriptive like 'Hide Additional Fields Based on Category'. Choose your target table from the Table dropdown. Set Type to 'onChange' since you want this to fire when users change a field value.
Use a naming convention like '[Controlling Field] - [Action]' so scripts stay organized as your form grows.
Configure the trigger field
In the Field name field, enter the exact field name (not label) of the field that will control visibility. This is the field users will interact with to show or hide other fields. Check the Active checkbox to enable the script. Leave UI Type as 'Desktop' unless you need different behavior on mobile.
Right-click any form field and select 'Configure Dictionary' to find its exact field name.
Write the basic visibility logic
In the Script field, start with a basic structure that gets the controlling field's value and uses if/else logic. Use g_form.getValue('field_name') to read the current value, then g_form.setDisplay('target_field', true/false) to show or hide dependent fields. Test with simple logic first — if the controlling field equals 'option1', show field A, otherwise hide it.
Use setDisplay instead of setVisible for cleaner forms — it removes hidden fields from the layout entirely.
Handle the initial form load
Add an onLoad client script with the same logic to handle cases where the form loads with the controlling field already set. Copy your onChange logic into a new client script with Type set to 'onLoad'. This ensures field visibility is correct when users open existing records or when default values are pre-populated.
Add null and empty checks
Wrap your visibility logic in checks for null, undefined, and empty string values. Use if (!controllingValue || controllingValue == '') to handle cases where the field is empty. Decide what the default visibility should be when no value is selected — typically you'll hide dependent fields until users make a choice.
Always test with empty forms and existing records to catch edge cases where field values might be null.
Test multiple scenarios thoroughly
Test the script by changing the controlling field value and verifying dependent fields show or hide correctly. Test with new records, existing records, and records where the controlling field changes multiple times. Verify that hidden field values are preserved when fields become hidden and visible again. Check that form layout doesn't break when multiple fields hide simultaneously.
Best practices
Use g_form.setDisplay() instead of setVisible() unless you specifically need to preserve whitespace — setDisplay creates cleaner, more professional-looking forms.
Always include both onChange and onLoad scripts with identical logic — users need correct field visibility whether they're changing values or opening existing records.
Put null checks before any field value comparisons to prevent JavaScript errors when fields are empty or undefined.
Consolidate related visibility logic into single scripts rather than creating separate onChange handlers for each controlling field — this prevents conflicts and makes maintenance easier.
Remember that hidden fields still submit their values when the form saves — if you need to clear hidden field data, explicitly set those fields to empty strings when hiding them.
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