GlideRecord

GlideRecord is the server-side Java-backed API for reading and writing table data. It is the single most-used class in ServiceNow, and almost every business rule, script include, scheduled job and background script leans on it. Understanding not just how to query but how GlideRecord behaves, lazy loading, journalled writes, dot-walking, and its performance envelope, separates a scripter who copies snippets from one who can be trusted with production data.

Every GlideRecord script is some combination of query, read, write, delete. The lifecycle is always: instantiate against a table, narrow with query conditions, execute, then iterate.

Two things to internalise. First, nothing touches the database until query(), building conditions is cheap, executing is not. Second, GlideRecord is a cursor: next() advances one row at a time; the whole result set is not loaded into memory at once.

The condition builder is richer than addQuery(field, value). The three-argument form takes an operator, and several helpers cover ORs, ranges and null checks.

Common operators: =, !=, >, <, >=, <=, IN, NOT IN, STARTSWITH, ENDSWITH, CONTAINS, DOES NOT CONTAIN, LIKE.

This is the number-one source of GlideRecord bugs. A field accessed directly (gr.assigned_to) returns a GlideElement object, not a string, it only looks like a string when concatenated. On a reference field that surprises people badly:

Rule: compare and store on getValue() (the sys_id); show the user getDisplayValue(). Always call getValue() explicitly rather than relying on implicit coercion, it makes intent obvious and avoids the object-vs-string trap in conditionals.

Because a reference field points at another record, you can walk across the relationship in one expression, no second query needed. GlideRecord resolves it for you:

Prefer setValue()/getValue() over direct assignment in scripts you care about, they are unambiguous about strings vs objects. insert() returns the new record's sys_id (or null if a data policy or ACL blocked it), and update() returns the sys_id of the updated row.

get() is the shortcut for fetching exactly one record, pass a sys_id, or a field/value pair. It returns a boolean so you can guard the block.

When you only need a count or a sum, never query all rows and count in a loop, that drags every record into memory. Use GlideAggregate, which pushes the maths to the database:

Date fields are best manipulated with GlideDateTime rather than string arithmetic, so time zones and DST are handled correctly:

• Filter at the database, not in script. Add every condition you can to the query; don't next() through everything and if inside the loop.
• Use setLimit() when you only need the first N rows, it stops the DB fetching more.
• Avoid getRowCount() on large tables, it can force a full scan; use GlideAggregate COUNT instead.
• Mind the query business rule. A GlideRecord run as a normal user is filtered by ACLs; setWorkflow(false) and autoSysFields(false) control whether business rules and audit fields fire on writes.
• GlideRecordSecure enforces ACLs in server scripts where you explicitly want row-level security applied.

• Forgetting query(), the loop silently never runs.
• Using a field in string context and getting a sys_id where you expected a name.
• Looping deleteRecord() or counting in script instead of deleteMultiple() / GlideAggregate.
• Unbounded bulk updates that fire business rules a million times.
• Assuming a server script sees all rows, as a non-admin user, ACLs filter the result.