sys_script_client Table

Table Reference/sys_script_client

The sys_script_client table stores Client Scripts—browser-side JavaScript that runs on forms during onLoad, onChange, onSubmit, and onCellEdit events. Owned by the Development module, these scripts control form behavior and field interactions in real-time.

What This Table Is

The sys_script_client table contains Client Scripts that execute in the user's browser to control form behavior. Unlike server-side Business Rules, these scripts run immediately as users interact with forms—validating data, hiding fields, making fields mandatory, or triggering alerts. Client Scripts are the primary mechanism for creating dynamic, responsive forms in ServiceNow.

Owned by the Development module, Client Scripts support four event types: onLoad (form initialization), onChange (field value changes), onSubmit (form submission), and onCellEdit (list editing). They work across regular forms, Service Catalog items, and mobile interfaces, though with important behavioral differences.

Client Scripts don't extend other tables—they're standalone records that apply to specific tables via the table field. Unlike Business Rules that can cascade through table inheritance, Client Scripts must be explicitly created for each table where you need them. Global Client Scripts (where global is true) run on all tables but have limited API access.

Large enterprises typically have 200-500 active Client Scripts. Performance matters because these scripts affect user experience directly—slow Client Scripts create laggy forms. The platform loads all applicable Client Scripts when a form opens, so excessive script count impacts page load times.

When You'll Script Against This Table

You'll query sys_script_client primarily in Script Includes and Business Rules when building administrative tools, custom form builders, or migration utilities. Server-side scripts commonly query this table to discover what Client Scripts exist, clone configurations between instances, or programmatically manage form behavior. Scheduled Jobs also use this table when auditing client-side customizations or generating documentation.

Access requires the admin role by default. The script field containing the JavaScript code has additional ACL restrictions—developers need explicit sys_script_client.script access to read or modify the actual code.

Clone Client Scripts between development, test, and production instances
Build admin utilities that bulk-disable Client Scripts for troubleshooting
Generate documentation showing which tables have client-side validation
Audit scripts for security issues like direct DOM manipulation or hardcoded values
Create custom form builders that generate Client Scripts programmatically
Find unused or duplicate scripts during platform cleanup efforts
Migrate table-specific scripts when consolidating or splitting table structures

Table Gotchas

⚠️

The ui_type field controls where scripts run: 0=Desktop, 10=Mobile, 0=Both. Setting this wrong means your script won't execute on mobile devices, which breaks mobile workflows.

⚠️

Global Client Scripts (global=true) can't access g_form.getReference() or other advanced APIs. They only get basic g_form methods, which trips up developers who copy code from table-specific scripts.

The condition field uses server-side syntax but runs before the script loads. Complex conditions can slow form loading because they're evaluated server-side first.
Client Scripts on Service Portal forms behave differently—some g_form methods aren't available, and the execution timing differs from regular forms.

⚠️

The applies_to field (not visible in lists) stores internal table inheritance data. Don't modify this directly—it's automatically maintained by the platform when you set the table field.

Order field values matter for onChange scripts targeting the same field. Lower numbers run first, but relying on execution order creates fragile code.
Scripts with active=false still appear in Studio and can be accidentally reactivated. Always check the condition to understand why a script was disabled.

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

The sys_db_object table defines which tables exist and is referenced by the table field. When building administrative tools, you'll join these tables to show human-readable table names instead of internal names. The sys_dictionary table is essential for onChange scripts—you need it to validate that the target field actually exists on the specified table.

The sys_script (Business Rules) and sys_ui_policy (UI Policies) tables work alongside Client Scripts to control form behavior. Developers often query all three together when analyzing how a form behaves—UI Policies for declarative field control, Client Scripts for custom JavaScript logic, and Business Rules for server-side validation. The sys_update_xml table tracks Client Script changes through Update Sets, making it crucial for deployment and rollback scenarios.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Key Fields

Column	Type	Label	Notes
name	string	Name	Human-readable script name. Must be unique per table—duplicates cause form loading issues.
table	string	Table	Internal table name where this script runs. Cannot be changed after creation without breaking form behavior.
type	choice	Type	Script execution timing: onLoad, onChange, onSubmit, onCellEdit. Determines available g_form methods and when the script fires.
script	script_plain	Script	The actual JavaScript code. Has separate ACL protection—requires explicit field access to read or modify.
active	boolean	Active	Controls script execution. Inactive scripts still load in Studio, creating confusion about what's actually running.
global	boolean	Global	Runs on all tables when true, but with limited g_form API access. Cannot use getReference() or advanced methods.
condition	conditions	Condition	Server-side condition evaluated before loading the script. Complex conditions slow form loading since they run server-side first.
field	string	Field name	Target field for onChange scripts. Must be exact field name—display labels don't work and cause silent failures.
ui_type	choice	UI Type	Execution context: 0=Desktop, 10=Mobile, All=Both. Wrong setting means scripts won't run on mobile devices.
order	integer	Order	Execution sequence for multiple scripts on same field/event. Lower numbers run first, but relying on order creates fragile code.
view	string	View	Specific form view where script runs. Empty means all views—use sparingly since it's hard to troubleshoot.
inherited	boolean	Inherited	Read-only flag indicating script comes from parent table. Cannot be directly modified—controlled by table inheritance.
applies_to	string	Applies to	Internal field storing table inheritance data. Automatically maintained by platform—manual changes break script loading.
description	string	Description	Documentation field that's often empty in production. Critical for maintenance since Client Script code lacks inline comments.
messages	string	Messages	UI messages displayed by the script. Stored as comma-separated keys that reference sys_ui_message records.

Common Queries

Get all active Client Scripts

// Most basic query - what every developer tries first
var gr = new GlideRecord('sys_script_client');
gr.addQuery('active', true);
gr.orderBy('table');
gr.orderBy('name');
gr.query();

while (gr.next()) {
    gs.info('Script: ' + gr.getValue('name') + ' on ' + gr.getValue('table'));
}

Find onChange scripts for specific table and field

// Real-world scenario: troubleshooting field behavior
var gr = new GlideRecord('sys_script_client');
gr.addQuery('active', true);
gr.addQuery('type', 'onChange');
gr.addQuery('table', 'incident');
gr.addQuery('field', 'priority');
gr.orderBy('order'); // Execution sequence matters
gr.query();

while (gr.next()) {
    gs.info('Found onChange script: ' + gr.getValue('name'));
    gs.info('Order: ' + gr.getValue('order'));
}

Audit mobile-compatible Client Scripts across all tables

// Business need: ensure mobile app compatibility
var gr = new GlideRecord('sys_script_client');
gr.addQuery('active', true);
gr.addQuery('ui_type', 'IN', '10,0'); // Mobile or All
gr.addQuery('global', false); // Skip globals - they're auto-compatible
gr.orderBy('table');
gr.query();

var mobileScripts = 0;
while (gr.next()) {
    mobileScripts++;
    gs.info(gr.getValue('table') + ': ' + gr.getValue('name'));
}
gs.info('Total mobile-compatible scripts: ' + mobileScripts);

Count Client Scripts by table using GlideAggregate

// Aggregate count for capacity planning
var ga = new GlideAggregate('sys_script_client');
ga.addQuery('active', true);
ga.groupBy('table');
ga.addAggregate('COUNT');
ga.orderByAggregate('COUNT'); // Tables with most scripts first
ga.query();

while (ga.next()) {
    var table = ga.getValue('table');
    var count = ga.getAggregate('COUNT');
    gs.info('Table: ' + table + ' has ' + count + ' Client Scripts');
}

Find scripts with empty conditions - common gotcha

// WRONG: querying condition field directly returns unexpected results
// var gr = new GlideRecord('sys_script_client');
// gr.addQuery('condition', ''); // This doesn't work as expected!

// RIGHT: use addNullQuery for empty conditions
var gr = new GlideRecord('sys_script_client');
gr.addQuery('active', true);
gr.addNullQuery('condition'); // Proper way to find empty conditions
gr.query();

while (gr.next()) {
    // These scripts run unconditionally - potential performance impact
    gs.info('Unconditional script: ' + gr.getValue('name'));
}

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue

sys_script_client