Script Background lets you run one-off server-side JavaScript for data fixes, bulk operations, or testing logic without building a full application. You'll have immediate script execution with full database access and your admin privileges.
Why Script Background exists
Before Script Background, admins doing bulk data fixes had to write full applications, create update sets, or manipulate data through forms one record at a time. That meant simple tasks like updating 500 records with a new value became hour-long manual processes, or required a developer to build temporary functionality that would get thrown away. Platform admins and developers need a way to run immediate server-side operations without the ceremony of building permanent features.
How Script Background works
Script Background is server-side JavaScript that runs immediately in the ServiceNow application server with your logged-in user's roles and domain scope. It's essentially a direct connection to the server-side scripting engine — the same environment where Business Rules and Script Includes execute. You write standard GlideRecord queries, call system APIs like gs.setProperty(), and manipulate data directly. The script inherits your security context, so it can access whatever tables and records your roles allow.
Production safety and best practices
Once you're comfortable with basic scripts, the discipline that separates safe admins from dangerous ones is rigorous non-production testing and conservative scripting practices. Always prototype on a development instance, use transaction limits to prevent runaway scripts, and build rollback logic before running destructive operations. Production-quality scripts include error handling, logging with gs.info(), and dry-run modes that show you what would change without actually changing it.
Before you start
- •admin role or elevated privileges to access System Definition
- •Non-production instance for testing (never run untested scripts on production)
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 Scripts Background
Go to System Definition > Scripts - Background. This opens the script execution interface where you'll write and run your JavaScript. The interface shows a large text area for your script and execution controls below it.
Write your server-side script
Enter your JavaScript in the script field. Use standard ServiceNow server-side APIs — GlideRecord for database operations, gs.info() for logging output, gs.setProperty() for system properties. The script runs in global scope, so you don't need to wrap it in functions unless you want to.
Start with gs.info('Script starting') and gs.info('Script complete') to confirm execution in the logs.
Set execution scope if needed
If your instance uses domain separation, verify the scope shows your intended domain in the application picker at the top right. The script inherits your current domain context and can only access records you have rights to see.
Add transaction limits for safety
For scripts that modify data, add a counter and break out of loops after a reasonable number of operations. Use something like 'if (count++ > 100) break;' inside your GlideRecord loops to prevent runaway scripts that could impact system performance.
Run the script and monitor output
Click Run script to execute immediately. Output from gs.info() and gs.print() appears in the Output section below the script. Any runtime errors also display here. The script runs synchronously — the interface won't respond until execution completes.
Verify results in target tables
Navigate to the affected tables or records to confirm your script worked as expected. Don't rely solely on the output messages — check the actual data. If you're updating records, spot-check a few to ensure the changes are correct.
Use gs.info() to output sys_ids of modified records so you can navigate directly to them for verification.
Best practices
Never run untested scripts on production — always prototype on development instances first and verify the logic works correctly.
Include transaction limits in any script that loops through records to prevent accidental performance impacts or infinite loops.
Use gs.info() liberally to log what your script is doing — the output helps with debugging and provides an audit trail of changes.
Build dry-run functionality into destructive scripts using a boolean flag that logs what would happen without actually making changes.
Always query for a small subset first to test your GlideRecord conditions before running against large datasets.
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