UI policy conditions and actions work for straightforward form control — hiding fields, making them required, setting values. When you need more complex logic or calculations, you can run custom JavaScript directly in the policy.
When basic UI policies aren't enough
Standard UI policy conditions check field values against static criteria, and actions manipulate field properties in predictable ways. That works until you need conditional logic that depends on multiple fields, calculations, or interactions with other form elements. Platform admins hit this wall when business rules are too complex for point-and-click configuration — you need the full power of JavaScript but want the policy to execute as the user interacts with the form.
How scripted UI policies work
Scripted UI policies run client-side JavaScript in the same browser context as client scripts — you have access to g_form, g_user, and all the usual client-side APIs. ServiceNow provides two script fields: 'Script (True)' executes when your condition evaluates to true, 'Script (False)' executes when it's false. The condition still matters — it determines which script runs. Most developers use the True script for the main logic and leave False empty, but you can implement different behaviors for each state.
When to choose scripts over client scripts
The main advantage of scripted UI policies over standalone client scripts is that they tie directly to your policy condition — when the condition changes, the appropriate script fires automatically. Use scripted policies when your logic is tightly coupled to a specific field state. For complex form interactions that span multiple conditions or need to persist across form sessions, dedicated client scripts are cleaner and easier to maintain. Most production implementations use scripted policies sparingly — they're harder to debug and version control than separate client scripts.
Before you start
- •ui_policy_admin or admin role
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
Open your UI Policy
Navigate to System UI → UI Policies and open the policy you want to add scripting to, or create a new one. If creating new, set your Table, Condition, and standard Actions first. The condition determines when your scripts will execute, so get this right before adding JavaScript.
Enable Run scripts checkbox
In the UI Policy form, check the 'Run scripts' checkbox in the main section. This unlocks the Script (True) and Script (False) fields below. Without this enabled, ServiceNow ignores any JavaScript you write in those fields.
Add your True condition script
In the 'Script (True)' field, write the JavaScript that should execute when your condition evaluates to true. You have access to g_form methods like getValue(), setValue(), setVisible(), and setMandatory(). This script runs in addition to any standard Actions you've configured on the policy.
Add False condition script if needed
If you need different behavior when the condition is false, add JavaScript to the 'Script (False)' field. Most policies leave this empty and handle the false state through standard UI Policy actions or other policies. Only populate this when you need custom logic for the false condition.
Test both condition states
Save the policy and open a form record. Change the fields that trigger your condition and verify both the True and False scripts execute as expected. Check browser console for any JavaScript errors. The policy should fire immediately when the condition changes, not just when you save the form.
Best practices
Keep scripted UI policies simple — complex logic belongs in client scripts where it's easier to debug and maintain.
Always check if the field exists before manipulating it — g_form.getValue('field_name') returns null if the field isn't on the form.
Don't query the server from UI policy scripts — use GlideAjax in client scripts instead if you need server data.
Use descriptive comments in your scripts since these are harder to find than standalone client scripts when troubleshooting.
Consider whether a client script with onChange would be clearer — scripted policies are best when the logic is truly tied to the policy condition.
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