sys_script Table — ServiceNow Reference

Table Reference/sys_script

The `sys_script` table stores Business Rule definitions - server-side scripts that execute on database operations. Owned by the System Definition module, this table defines when, where, and what code runs during record lifecycle events.

What This Table Is

The sys_script table contains Business Rule definitions - the metadata that tells ServiceNow when and how to execute server-side JavaScript during database operations. Each record defines a script that can fire before, after, on display, or asynchronously when records are inserted, updated, deleted, or queried on specific tables.

This table is owned by the System Definition module and serves as the foundation for all server-side automation in ServiceNow. Business Rules defined here execute automatically based on database events, making them crucial for data validation, calculations, integrations, and workflow automation across the entire platform.

The sys_script table extends sys_metadata and inherits standard metadata fields for application scoping, update sets, and version control. No tables extend sys_script directly, but it references many tables through its collection field that specifies which table the Business Rule applies to.

Large enterprises typically have 3,000-8,000 Business Rules across all applications. Performance is generally excellent for queries by collection (indexed) but can be slow when searching script content or advanced conditions. The platform caches active Business Rules aggressively, so metadata changes require cache clearing to take effect.

When You'll Script Against This Table

You'll primarily query sys_script in Script Includes for dynamic rule discovery, in Business Rules that need to check other rules, and in scheduled jobs that audit or manage Business Rule configurations. Administrative interfaces and custom applications also query this table to display rule information or validate configurations.

Access requires the admin role for full read/write access, though scoped applications can read their own Business Rules with appropriate delegated development roles. The table respects application scope boundaries - global scripts can see all rules, but scoped applications only see their own.

Finding all Business Rules that execute on a specific table for impact analysis
Searching script content to locate rules using specific APIs or field references
Auditing rule execution timing and conditions to optimize performance
Dynamically enabling/disabling Business Rules based on system conditions
Building custom admin interfaces that manage or report on Business Rule configurations
Creating deployment scripts that validate Business Rule dependencies
Implementing rule execution monitoring and alerting for critical automations

Table Gotchas

⚠️

Business Rules are cached aggressively. Changes to sys_script records don't take effect until the cache is cleared or the instance is restarted. Always test rule changes after modifying this table directly.

The collection field stores the table name as a string, not a reference - query using string values, not sys_ids

⚠️

The 'when' field uses integer values: 'before'=1, 'after'=2, 'async'=4, 'display'=8. Multiple timings are bitwise OR'd together, so a rule with before+after timing has when=3.

Advanced conditions in the condition field use encoded condition strings - not directly readable without parsing
Queries against the script field (script content) are extremely slow on large instances - avoid CONTAINS queries in production

⚠️

Business Rules marked as 'Global' (is_rest=false) execute for all database operations on their table, including integrations and bulk operations. This can cause unexpected performance issues.

The order field controls execution sequence but only within the same timing (before/after/async) - before rules always run before after rules regardless of order

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_script table extends sys_metadata, inheriting application scoping and update set tracking capabilities. This relationship is crucial for understanding how Business Rules are packaged and deployed across instances. The sys_scope field links to application records for scoped Business Rules.

Business Rules commonly reference sys_db_object through their collection field to determine which tables they execute against. The sys_user table is frequently joined when auditing who created or modified Business Rules. For debugging and monitoring, developers often correlate sys_script records with execution logs in syslog or syslog_transaction tables.

When building comprehensive automation reports or impact analysis tools, developers typically join sys_script with related automation tables like wf_workflow (workflows), sys_ui_action (UI actions), and sys_script_include (Script Includes) to understand the complete automation landscape for a given table or application.

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	The display name of the Business Rule. Must be unique within the same application scope.
collection	string	Table	The table name this Business Rule executes against. Stored as a string (e.g., 'incident'), not a reference to sys_db_object.
active	boolean	Active	Controls whether the Business Rule executes. Inactive rules are completely ignored by the platform and don't impact performance.
when	choice	When	Execution timing using bitwise values: before=1, after=2, async=4, display=8. Multiple timings are OR'd together (e.g., before+after=3).
order	integer	Order	Execution sequence within the same timing. Lower numbers execute first, but before rules always run before after rules regardless of order.
script	script	Script	The JavaScript code to execute. Contains queries against this field are extremely slow and should be avoided in production.
condition	conditions	Condition	Encoded condition string that determines when the rule executes. Simple conditions are readable, but advanced conditions require parsing.
filter_condition	string	Filter Condition	Additional JavaScript condition evaluated before script execution. Provides more flexibility than the encoded condition field.
abort_action	boolean	Abort Action	When true, allows the Business Rule to prevent database operations by calling current.setAbortAction(true) in before rules.
advanced	boolean	Advanced	Enables advanced scripting features and removes some platform guardrails. Should be used sparingly for performance reasons.
rest_service	boolean	REST Service	When true, the rule executes for REST API operations. When false, it's considered 'Global' and executes for all database operations.
is_rest	boolean	Execute on REST	Controls execution for REST operations. Opposite behavior from rest_service - when false, rule executes for all operations including REST.
template	reference	Template	References sys_template for mail script Business Rules. Links the rule to notification templates for email processing.
sys_domain	domain_id	Domain	Domain scope for the Business Rule. Controls visibility and execution based on the user's domain in multi-domain instances.
role_conditions	string	Role Conditions	Comma-separated list of roles required for the rule to execute. Empty means no role restrictions apply.
add_message	boolean	Add Message	When true, allows the Business Rule to add messages to the user interface using gs.addInfoMessage() and similar methods.
priority	integer	Priority	Execution priority within the same order value. Higher priority rules execute first when order values are equal.
sys_class_name	string	Class	Always 'sys_script' for Business Rules. Used internally for metadata classification and inheritance.
sys_scope	reference	Application	References sys_scope to indicate which application owns this Business Rule. Critical for scoped application boundaries.

Common Queries

Get all active Business Rules for a specific table

// Most basic query - find active rules for incident table
var gr = new GlideRecord('sys_script');
gr.addQuery('active', true);
gr.addQuery('collection', 'incident');
gr.orderBy('when'); // Group by timing
gr.orderBy('order'); // Then by execution order
gr.query();

while (gr.next()) {
    gs.info('Rule: ' + gr.name + ', Timing: ' + gr.when + ', Order: ' + gr.order);
}

Find Business Rules by timing and application scope

// Find all before rules in a specific application
// Uses bitwise AND to check timing flags
var gr = new GlideRecord('sys_script');
gr.addQuery('active', true);
gr.addQuery('when', 'CONTAINS', '1'); // Before timing
gr.addQuery('sys_scope.name', 'ITSM Application');
gr.orderBy('collection');
gr.query();

while (gr.next()) {
    gs.info(gr.collection + ': ' + gr.name);
}

Audit Business Rules that might impact performance

// Find advanced async rules without conditions - potential performance impact
// Real scenario: preparing for performance review
var gr = new GlideRecord('sys_script');
gr.addQuery('active', true);
gr.addQuery('advanced', true);
gr.addQuery('when', 'CONTAINS', '4'); // Async timing
gr.addQuery('condition', 'ISEMPTY'); // No filtering condition
gr.orderBy('collection');
gr.query();

gs.info('Found ' + gr.getRowCount() + ' potentially expensive async rules');
while (gr.next()) {
    gs.info(gr.collection + '.' + gr.name + ' - Review for optimization');
}

Count Business Rules by table using GlideAggregate

// Get rule count per table for capacity planning
var ga = new GlideAggregate('sys_script');
ga.addQuery('active', true);
ga.groupBy('collection');
ga.addAggregate('COUNT');
ga.orderByAggregate('COUNT');
ga.query();

while (ga.next()) {
    var table = ga.getValue('collection');
    var count = ga.getAggregate('COUNT');
    gs.info('Table ' + table + ' has ' + count + ' active Business Rules');
}

Wrong way vs right way to query script content

// WRONG: This will timeout on large instances
// var gr = new GlideRecord('sys_script');
// gr.addQuery('script', 'CONTAINS', 'gs.eventQueue');

// RIGHT: Limit scope first, then search content if needed
var gr = new GlideRecord('sys_script');
gr.addQuery('active', true);
gr.addQuery('collection', 'incident'); // Narrow scope first
gr.addQuery('when', 'CONTAINS', '4'); // Only async rules
gr.query();

// Then filter in JavaScript for better performance
while (gr.next()) {
    if (gr.script.toString().indexOf('gs.eventQueue') > -1) {
        gs.info('Found event queue usage in: ' + gr.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