Glide Record is one of the core server-side APIs for reading and changing ServiceNow records, but the important design question is not how to call query(). It is how query conditions, indexes, ACL/application boundaries, loop behavior, business rules, and the surrounding transaction interact. The CAD exam context makes this systems view useful because a script that returns the right rows in a small test can still be unsafe or slow in production.
ServiceNow’s current developer guidance describes the basic pattern clearly: create a GlideRecord for the table, add conditions, execute the query, and iterate through returned records. It also warns that a query with no conditions returns all records and that malformed conditions can have surprising behavior depending on instance settings.
The database fundamentals behind building a database still apply. Queries should ask for the smallest useful data set, follow indexed/selective fields where practical, and preserve the business rules and security boundaries the application depends on.
Build the query before executing it
Create the GlideRecord object and add all intended conditions before calling query().
Use explicit field names, operators, and values so the query’s meaning is visible in code review.
Start from list filters when useful: build the condition interactively, validate the result set, copy the encoded query, and then break it into readable parts if that improves maintainability.
Query construction should also include explicit handling for null and empty values. In ServiceNow, an empty value can be a valid filter state rather than ‘no filter.’ Decide whether blank input should match empty fields, return nothing, or be rejected. That prevents user-supplied optional filters from accidentally broadening a query.
Dynamic query builders should use allow-lists for field names and operators when those elements come from user or integration input. Validating only the value is not enough if a caller can choose an arbitrary field or operator and broaden the query. Restrict the supported query grammar to what the business workflow genuinely needs.
No condition means every record
A GlideRecord query without conditions can return an entire table.
That may be intentional for a small reference table and dangerous for Incident, Task, CMDB, or another large table.
Guard scripts that accept user or integration input so an empty value does not accidentally remove the only selective condition and turn one lookup into a full-table scan.
Encoded queries should be treated as a small language. AND, OR, grouping, relative dates, and operators can become difficult to reason about when concatenated dynamically. Build complex conditions with tested helper functions or GlideQueryCondition objects where that makes intent clearer, and keep user input out of raw encoded strings unless it is safely validated.
Encoded queries are compact and need discipline
addEncodedQuery() can represent complex AND/OR conditions compactly.
Compact syntax can become hard to review when logic is assembled through string concatenation.
Keep static parts readable and validate dynamic values before adding them. A script should make it clear which conditions are mandatory and which are optional.
Selectivity should be tested on production-like row counts. A query that completes instantly against a thousand development records can become a transaction bottleneck against millions. Use slow-query logs, execution plans where supported, and index guidance before optimizing based only on script execution timing in a small PDI.
Index requests should follow measured slow queries. Creating indexes for every field that appears in a script can slow writes and increase maintenance without helping real workloads. Collect representative query patterns and record counts, then work with platform guidance to select indexes that improve the highest-value conditions.
Selectivity affects performance
Queries on indexed and selective fields generally scale better than broad conditions on unindexed text.
Filter early and avoid returning fields or records the script will immediately discard in JavaScript.
Use platform query diagnostics and database/index guidance for high-volume tables rather than guessing from one developer instance with little data.
Querying display values can be more expensive and ambiguous than querying stable internal values. Use sys_id and stored field values for joins/filters where possible, then convert to display values at presentation boundaries. Stable identifiers reduce surprises when labels or user-facing names change.
References create additional access patterns
Following a reference can simplify code and can produce repeated database lookups inside a loop.
The relationship concepts behind data retrieval across related tables are useful because developers should understand whether they are making one selective query or hundreds of dependent lookups.
Where appropriate, restructure the query, cache repeated values, or use a platform API designed for the required relationship instead of performing uncontrolled nested loops.
Reference traversal inside loops should be counted. Calling getRefRecord or dot-walking several levels for every returned row can produce many additional database operations. Cache repeated references and reconsider the data-access pattern when the same related record is fetched hundreds of times in one transaction.
Loop behavior determines transaction cost
Every next() iteration can trigger script logic, lookups, calculations, and updates.
A query returning ten thousand rows can become expensive even when the database fetch itself is fast.
Limit result sets, process in batches where appropriate, and move heavy asynchronous work out of synchronous user transactions when the business does not require immediate completion.
Bulk processing should use windows or checkpoints when one long transaction would risk timeout. Scheduled jobs, fix scripts, or background operations can process deterministic batches and record progress. This also makes recovery easier because a failed run resumes from a known boundary instead of reprocessing the entire table.
Batch jobs should define an ordering key and restart behavior. If a batch updates records by sys_id and one run stops midway, it should resume without skipping or reprocessing unpredictably. Store a checkpoint and design the update to be safe when a record changes between batches.
Writes trigger more than one database operation
insert(), update(), and deleteRecord() can invoke Business Rules, flows, auditing, notifications, and other automation.
A loop that updates hundreds of records can therefore execute a much larger chain than the GlideRecord lines suggest.
Understand the downstream behavior before bulk updates, and avoid suppressing workflow or business logic unless the application has a reviewed reason and compensating validation.
Write behavior should consider recursion and audit. Updating the same record from Business Rules triggered by update() can cause repeated execution unless conditions prevent it. Suppressing workflow or auto fields may be appropriate in carefully controlled maintenance scripts and should never be the default way to make an expensive update loop finish faster.
Bulk writes should avoid disabling business rules indiscriminately. setWorkflow(false) or similar techniques can be necessary in controlled data maintenance and can bypass auditing, synchronization, or validation the application relies on. If used, document which side effects are intentionally suppressed and run separate reconciliation checks afterward.
Scope and access policy can block otherwise valid queries
An out-of-scope script may be prevented from reading or changing a table by Application Access and cross-scope policy.
Users may also face ACL restrictions when code is executed through user-facing paths.
The general RBAC principle remains useful: data access should be evaluated in the context of who or what is acting, not merely whether the table exists.
Do not widen table access globally just to make one script work. Review whether the application should use a narrower supported interface.
Cross-scope access errors should be solved at the right boundary. If a scoped app legitimately needs a global record, confirm the target table’s Application Access and required cross-scope privilege. If direct table access would bypass the target application’s business logic, expose a supported interface instead of granting broader CRUD permissions.
Good query code is observable and testable
Log or trace high-value failures without dumping sensitive record content.
Test empty input, invalid sys_ids, no matches, many matches, cross-scope access, slow tables, and records that trigger downstream automation.
The broader data-quality accountability perspective matters because a fast query that returns the wrong business records is still a production defect.
A strong GlideRecord pattern makes selection logic, access assumptions, performance boundaries, and downstream side effects visible enough that another developer can reason about the transaction without executing it blindly.
Testing should include security context. Server-side scripts running as admin or system can return records that ordinary users cannot see through their application. If the result is displayed or acted on for a user, use the appropriate security-aware APIs or ACL checks according to the design. Data correctness includes not returning records the caller is not authorized to consume.
GlideRecord code review should include expected row count. A reviewer can reason about a loop much better when the script states whether it expects one record, tens, or hundreds of thousands. Add limits or getRowCount only where appropriate and use logs/metrics for unexpectedly large results so a data-growth change becomes visible before it turns into transaction timeouts.
Query code should also avoid unnecessary writes used only to trigger downstream behavior. If a script updates a record with the same values simply to invoke a Business Rule, the coupling is hidden and can create audit noise or recursion. Prefer an explicit reusable function or event when the real intent is to invoke logic rather than to change the record.
Performance reviews should inspect how often the same query runs. A moderately expensive GlideRecord executed once in a nightly job can be acceptable; the same query inside a Business Rule that fires on every update can become a major platform cost. Frequency, row count, selectivity, and downstream script work determine total impact together, so optimization should begin with the full execution pattern rather than one query duration.
