What It Does

The addNotNullQuery() method adds an IS NOT NULL condition to your GlideRecord query. When executed, it filters out any records where the specified field contains a null value, empty string, or undefined value. The method appends this condition to your existing query using an AND operator, meaning all conditions must be satisfied.

Internally, ServiceNow translates this to a SQL IS NOT NULL clause against the database column. The platform treats empty strings and null values identically for this operation, so both will be excluded from your results. Reference fields that point to non-existent records are also considered null and will be filtered out.

The method returns a GlideQueryCondition object that represents the condition you just added. This return value allows you to further modify the condition using methods like addOrCondition() or to chain additional query modifications. The GlideQueryCondition is never null - even if you pass an invalid field name, you'll still get a condition object back.

For choice fields, the method checks whether the field has any value selected, not whether it has a specific choice value. Date/time fields are considered null when they haven't been set or when they've been explicitly cleared. Boolean fields can only be null in rare cases where they've been explicitly set to null via direct database manipulation.

This method works identically to addQuery(field, '!=', '') in most cases, but addNotNullQuery() is more semantically clear and generates cleaner SQL. It pairs with addNullQuery() which does the opposite operation.

When to Use This

Use addNotNullQuery() when you need to filter out records with empty reference fields, ensure required data exists before processing, or exclude records that haven't been fully configured. This is particularly common when working with assignment groups, user references, or configuration items that must have valid relationships to function properly.

Don't use this method when you need to check for specific values - use addQuery() instead. Also avoid it when you need to include records with empty values in your results - that's the default behavior without any null-checking conditions. If you need to find null values specifically, use addNullQuery() instead.

A common mistake is using this method to validate data before inserting or updating records. GlideRecord queries are for retrieving data - use proper validation in Business Rules or client scripts for data integrity checks.

Return Value

The method returns a GlideQueryCondition object that represents the IS NOT NULL condition you just added to the query. This object allows you to further modify the condition using methods like addOrCondition(), addCondition(), or other condition methods to build complex query logic.

The return value is never null, even if you pass an invalid field name. However, querying with an invalid field name will cause the query execution to fail when you call query(). You can safely chain methods on the returned GlideQueryCondition without checking for null, but always validate field names before building your query.

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

No spam · Unsubscribe anytime

Platform Behavior & Side Effects

  • No Business Rules, ACLs, or other platform events fire when adding query conditions - they only fire during actual database operations like insert, update, or delete
  • Nothing gets written to the database until you call query() followed by iteration methods - this method only builds the query structure in memory
  • Performance is excellent - adding query conditions is a fast, in-memory operation that doesn't hit the database
  • The method works identically in all server-side contexts - Business Rules, Script Includes, Scheduled Jobs, and Background Scripts
  • Query conditions are not cached - each GlideRecord instance builds its own query structure independently
  • The resulting SQL IS NOT NULL condition respects field-level ACLs when the query executes, potentially filtering out additional records the user lacks permission to see