GlideRecord.addQuery() Operators

What It Does

The addQuery() method builds WHERE clauses for database queries by accepting an explicit operator. ServiceNow translates this into SQL WHERE conditions that filter records before they're returned from the database. Unlike the two-parameter version that assumes equality, this three-parameter version gives you full control over comparison logic.

Internally, ServiceNow builds a query object that gets converted to SQL when you call query() or iteration methods. Each addQuery() call adds an AND condition to the WHERE clause. The method validates field names at query execution time, not when you call addQuery(), so invalid field names will cause runtime errors.

The method always returns a GlideQueryCondition object, never null or undefined. This return object represents the specific condition you just added and enables method chaining for OR operations. You can safely ignore the return value if you're only building AND conditions, but you'll need it for complex logic involving OR clauses.

Edge cases include empty string values (which match empty fields), null values (which ServiceNow converts to empty strings), and reference field queries that use sys_ids internally regardless of display values you might pass. The INSTANCEOF operator only works on tables with inheritance hierarchies and compares the table name, not record data.

This method works alongside addEncodedQuery() and the two-parameter addQuery() version. You can mix all three approaches in a single GlideRecord instance, and ServiceNow will AND them together. However, mixing approaches reduces code readability and makes debugging more difficult.

When to Use This

Use addQuery() when you need explicit control over comparison operators or when building queries programmatically where the operator might vary. This is particularly valuable for searches involving ranges (less than, greater than), pattern matching (CONTAINS, STARTSWITH), or set operations (IN, NOT IN). The method shines when you need the returned GlideQueryCondition for OR operations.

For simple equality comparisons, use the two-parameter addQuery(field, value) version instead—it's cleaner and more readable. When you have complex queries with multiple OR conditions, consider addEncodedQuery() with encoded query strings from the platform's condition builder. Avoid this method for queries that users might modify through the UI—those should use addEncodedQuery() with user-provided encoded strings.

Return Value

Returns a GlideQueryCondition object that represents the specific WHERE condition you just added. This object has methods like addOrCondition() for building OR logic within your query. The object is tied to the specific GlideRecord instance and condition—you cannot reuse it across different GlideRecord objects.

The method never returns null, undefined, or false, even if you provide invalid parameters. Invalid field names or operators will cause errors at query execution time, not during the addQuery() call itself. You can safely chain calls or store the return value without null checking.

Platform Behavior & Side Effects

• No database activity or Business Rules fire during addQuery() calls—the method only builds the query object in memory
• ACLs and Field-level Security apply when the query executes, not when conditions are added
• Performance is excellent for condition building—the overhead is minimal compared to actual query execution
• Reference field queries automatically resolve to sys_id values during execution, regardless of display values used
• Query conditions are cached within the GlideRecord instance but not across multiple instances
• Works identically in Business Rules, Script Includes, and Scheduled Jobs—no behavioral differences based on execution context
• Database indexes are utilized when appropriate field/operator combinations match existing indexes