GlideRecord.addActiveQuery()

addActiveQuery()→ void

beginnerTested on Xanadu

What It Does

The addActiveQuery() method adds a query condition that filters results to only include records where the 'active' field equals true. When ServiceNow executes the query, it translates this into a SQL WHERE clause that checks active = 1 in the database.

Internally, ServiceNow treats this method identically to calling addQuery('active', true). The method exists purely as syntactic sugar to make code more readable and express intent more clearly. When you build the query, ServiceNow adds this condition to its internal query builder along with any other conditions you've specified.

The method returns void — it modifies the GlideRecord object's query conditions but doesn't return anything. The filtering only takes effect when you call query() to execute the query. If no records match your conditions (including the active filter), the subsequent next() calls will return false.

⚠️

If you call addActiveQuery() on a table that doesn't have an 'active' field, ServiceNow will throw a runtime error when you execute the query.

The method works identically to other GlideRecord query methods like addQuery() and addNullQuery() — you can chain multiple conditions together, and they combine with AND logic. You can call addActiveQuery() before or after other query conditions without affecting the final result.

When to Use This

Use addActiveQuery() when you need to query tables where the 'active' field represents whether records should be considered current or valid. Most ServiceNow configuration tables (users, groups, locations, categories) use the active field to indicate whether the record is currently in use. This method makes your code's intent explicit — you're specifically looking for active records, not accidentally including inactive ones.

Don't use this method when you need inactive records or when you need both active and inactive records. In those cases, either skip the active filter entirely or use addQuery('active', false) for inactive records specifically. Also avoid using this on tables that don't have an active field — check the table schema first, especially when working with custom tables or tables you're unfamiliar with.

Return Value

The method returns void — it doesn't return any value. The method modifies the GlideRecord object's internal query state and returns control to your script. You cannot chain method calls off addActiveQuery() because there's nothing to chain from.

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.

Platform Behavior & Side Effects

No database queries execute when you call this method — it only modifies the query builder
Business Rules, ACLs, and other query-time mechanisms don't fire until you call query()
Performs identically to addQuery('active', true) with no performance difference
Will cause a runtime error if called on tables without an 'active' field when the query executes
Works in all server-side contexts (Business Rules, Script Includes, Scheduled Jobs, UI Actions)
Does not trigger audit entries or field-level security checks until query execution
Can be called multiple times on the same GlideRecord without error (though redundant)

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Code Examples

Basic active user lookupbasic

// Find all active users in the IT department
var gr = new GlideRecord('sys_user');
gr.addActiveQuery();
gr.addQuery('department', 'IT');
gr.query();

var activeUsers = [];
while (gr.next()) {
    activeUsers.push({
        name: gr.getDisplayValue('name'),
        email: gr.getValue('email'),
        sys_id: gr.getUniqueValue()
    });
}

gs.info('Found ' + activeUsers.length + ' active IT users');

This example shows the most common pattern — filtering to active records when you need current, valid data. The active filter ensures you don't get terminated employees or disabled accounts.

Combining with multiple conditionsintermediate

// Find active incident categories for a specific service offering
var gr = new GlideRecord('u_incident_category');
gr.addActiveQuery();
gr.addQuery('u_service_offering', serviceOfferingSysId);
gr.addQuery('u_priority', 'IN', '1,2,3'); // High priority categories only
gr.orderBy('order');
gr.query();

var categoryChoices = [];
while (gr.next()) {
    // Only active categories will appear in dropdown
    categoryChoices.push({
        value: gr.getUniqueValue(),
        label: gr.getDisplayValue('name')
    });
}

return categoryChoices;

Multiple query conditions work together with AND logic. This pattern is common when building dynamic choice lists where you only want active, relevant options displayed to users.

The classic mistake — checking field existenceadvanced

// WRONG: This will break on tables without 'active' field
var gr = new GlideRecord('incident');
gr.addActiveQuery(); // Error! Incident table uses 'state', not 'active'
gr.query();

// RIGHT: Check if field exists or use appropriate field
var gr = new GlideRecord('sys_user');
if (gr.isValidField('active')) {
    gr.addActiveQuery();
} else {
    // Use the correct field for this table
    gr.addQuery('state', '!=', '7'); // For incident table
}
gr.query();

Many tables use different fields to indicate record status. Always verify the table schema before using addActiveQuery() — incident tables use 'state', task tables vary by type.

Gotchas

The method will cause a runtime error if called on tables that don't have an 'active' field, but the error only appears when you execute query(), not when you call addActiveQuery().

Some ServiceNow tables use different fields for active status — incident uses 'state', knowledge articles use 'workflow_state', so addActiveQuery() won't work on these tables.

Calling addActiveQuery() multiple times on the same GlideRecord is redundant but won't cause errors — ServiceNow will just add multiple identical conditions to the query.

The active field stores boolean values as integers in the database (1 for true, 0 for false), but addActiveQuery() handles this conversion automatically.

Custom tables created without an 'active' field will fail at query time, even if the field was added later but the table dictionary wasn't properly updated.

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue