| NowSpectrum | Issue #4 · Weekly Tips |
Hey {{first_name}}, 👋
Quick one this week — most ServiceNow performance problems don't come from complex logic. They come from a single pattern repeated across dozens of scripts: querying inside a loop.
The Problem
Here is a pattern that exists in a huge number of ServiceNow instances — it works, it returns correct data, but it is silently destroying instance performance at scale.
var gr = new GlideRecord('incident'); gr.query(); while (gr.next()) { var user = new GlideRecord('sys_user'); user.get(gr.caller_id); // ← fires once per row! }
500 incidents = 501 database queries instead of 1. On a busy instance this stacks up across every transaction running in parallel.
The Fix — Dot-Walking
GlideRecord resolves reference fields automatically via dot-walking — no second query needed. Same data, fraction of the database load.
var gr = new GlideRecord('incident'); gr.query(); while (gr.next()) { var name = gr.caller_id.name.toString(); // ✓ var email = gr.caller_id.email.toString(); // ✓ // 1 query total — no extra round-trip }
Same 500 incidents = 1 database query. The dot-walk resolves the reference in memory — no round-trip to the database.
Where To Look First
| → | Business Rules on large tables — incident, task, sc_req_item |
| → | Script Includes called from catalog items or workflows at scale |
| → | Scheduled Jobs processing hundreds or thousands of records |
Search your scripts for new GlideRecord inside a while(gr.next()) loop. That's your audit list.
| The full GlideRecord performance breakdown — encoded queries, field-level querying, and the setLimit trick — is on nowspectrum.com | Read full article → |
— The NowSpectrum Team
| NowSpectrum | nowspectrum.com |