Mastering ServiceNow Queries: How addActiveQuery() Simplifies Your Code

Hey there, fellow ServiceNow enthusiast! Ever felt like your scripts are getting a bit verbose, especially when you’re constantly trying to grab just the “active” records? You’re not alone. In the fast-paced world of ServiceNow development, efficiency, readability, and maintainability are gold. And that’s exactly where methods like addActiveQuery() come into play. It’s not just a fancy method; it’s a game-changer for clean, effective server-side scripting.

Today, we’re going to deep dive into one of my favorite GlideRecord methods – addActiveQuery(). We’ll explore what it is, why it matters, and how it can make your ServiceNow development life a whole lot easier. So, grab your coffee, and let’s unravel the magic!

Understanding the Foundation: The Glide API and GlideRecord

Before we jump into the specifics of addActiveQuery(), let’s quickly set the stage. If you’re building custom functionalities, integrating systems, or just automating processes in ServiceNow, you’re undoubtedly working with the Glide API.

What is the Glide API?

Think of the Glide API as ServiceNow’s powerful toolkit for developers. It’s a collection of JavaScript classes and methods that allow us to interact with the platform’s underlying data, processes, and UI from our scripts. Instead of writing raw SQL queries, which ServiceNow generally prevents direct access to for security and platform integrity reasons, we use these APIs to perform database operations, manipulate records, and much more. This approach ensures consistency, security, and leverages ServiceNow’s robust data model.

Enter GlideRecord: Your Database Sidekick

Among the many useful classes in the Glide API, GlideRecord stands out as the most common and arguably the most crucial for server-side scripting. It’s a special JavaScript class, executed on the server, designed specifically to interact with ServiceNow tables (which, remember, are essentially database tables). Its primary purpose? To perform the fundamental CRUD operations (Create, Read, Update, Delete) on records, all without you ever having to write a single line of SQL!

Here’s why GlideRecord is your go-to:

• Database Abstraction: You deal with records and fields, not tables and columns. GlideRecord translates your requests into optimized SQL behind the scenes.
• Server-Side Power: It runs directly on the ServiceNow server, making it highly efficient for manipulating large datasets.
• CRUD Operations: From fetching existing records to creating new ones, updating fields, or deleting outdated data, GlideRecord handles it all.
• Security & Integrity: By using GlideRecord, you automatically adhere to ServiceNow’s security model (ACLs) and data integrity rules, reducing the risk of accidental data corruption.

Key GlideRecord Methods: A Glimpse

GlideRecord comes packed with a plethora of methods, each serving a unique purpose. While we won’t list them all (there are truly a lot!), here’s a snapshot of some common ones, with a special highlight on our star of the show:

• query(): Executes the constructed query.
• addQuery(): Adds a condition to your query.
• addActiveQuery(): Our focus! Adds a condition for active records.
• addEncodedQuery(): Adds a complex, pre-built query string.
• addInactiveQuery(): Adds a condition for inactive records.
• next(): Moves to the next record in the query result set.
• insert(): Creates a new record.
• update(): Saves changes to an existing record.
• deleteRecord() / deleteMultiple(): Deletes records.
• get(): Retrieves a single record by Sys ID or other unique fields.
• setLimit(): Limits the number of records returned.
• orderBy() / orderByDesc(): Sorts the results.
• And many, many more for field manipulation, relationship handling, and record validation.

Building Blocks of Querying: A Path to addActiveQuery()

Let’s walk through how queries are typically built, showing how addActiveQuery() fits into the picture and why it’s such an elegant solution.

1. The Basics: addQuery(), query(), and while(gr.next())

This is your fundamental pattern for fetching records. You instantiate a GlideRecord object, add your conditions, execute the query, and then loop through the results.

var inc = new GlideRecord('incident');
inc.addQuery('priority', '1'); // Add a simple condition: priority is 1
inc.query();                   // Execute the query
while(inc.next()){             // Iterate through each matching record
    gs.print(inc.number + ' - ' + inc.short_description); // Print some details
}
// Result: Prints all incident numbers and short descriptions where priority is 1.

Here, addQuery('priority', '1') is equivalent to `priority = 1` in SQL. Simple, right?

2. Stacking Conditions: Multiple addQuery() Calls

What if you need more than one condition? Just stack your addQuery() methods. GlideRecord automatically treats multiple addQuery() calls as logical AND operations.

var inc = new GlideRecord('incident');
inc.addQuery('active', 'true');      // Condition 1: Active records
inc.addQuery('priority', '1');      // Condition 2: Priority is 1
inc.addQuery('category', 'software'); // Condition 3: Category is software
inc.query();
while(inc.next()){
    gs.print(inc.number + ' - ' + inc.short_description);
}
// Result: Prints all active, priority 1 incidents with a category of 'software'.

This approach works perfectly well, but imagine if you have many conditions – your script can start looking a bit lengthy.

3. The Power of Conciseness: addEncodedQuery()

For more complex or numerous conditions, addEncodedQuery() is a lifesaver. It allows you to pass an entire query string (like the one you see in the filter breadcrumbs on a list view) as a single parameter. This is fantastic for readability and maintaining complex logic.

Pro Tip: How to get an Encoded Query from the UI:

1. Navigate to any list view (e.g., “Incident > All”).
2. Apply your desired filters (e.g., “Active is true AND Priority is 1 AND Category is Software”).
3. Right-click on the filter breadcrumbs (or click the “Filter” icon, then “Copy query”).
4. Select “Copy query” or “Copy URL” and extract the query string. It will look something like active=true^category=software^priority=1.

Now, use it in your script:

var encodedQuery = 'active=true^category=software^priority=1'; // Our copied query string
var inc = new GlideRecord('incident');
inc.addEncodedQuery(encodedQuery); // Pass the entire string
inc.query();
while(inc.next()){
    gs.print(inc.number + ' - ' + inc.short_description);
}
// Result: Same as the multiple addQuery() example, but more compact!

This is super efficient, especially when dealing with complex OR conditions that are tricky to build with just `addQuery()`.

4. Advanced `addQuery()` Syntax: Operators and Values

The addQuery() method isn’t just for simple equality. You can use a three-parameter version to specify an operator, giving you more flexibility.

inc.addQuery('field_name', 'operator', 'value');

Common operators include:

• = (equals)
• != (does not equal)
• > (greater than)
• >= (greater than or equal to)
• < (less than)
• <= (less than or equal to)
• IN (is one of)
• NOT IN (is not one of)
• STARTSWITH, ENDSWITH, CONTAINS, DOES NOT CONTAIN

Let's see an example:

var inc = new GlideRecord('incident');
inc.addQuery('priority', '<=', '2'); // Priority is Critical (1) or High (2)
inc.addQuery('short_description', 'CONTAINS', 'SAP'); // Short description contains 'SAP'
inc.query();
while(inc.next()){
    gs.print(inc.number + ' - ' + inc.short_description);
}
// Result: Prints incident numbers and short descriptions for tickets with priority 1 or 2, and 'SAP' in their short description.

The Star of the Show: Simplifying with addActiveQuery()

Now, let's bring it back to our main topic. You might have noticed in previous examples how often we need to filter for "active" records. Whether it's active incidents, open tasks, or active users, it's a very common requirement. Traditionally, you'd write:

inc.addQuery('active', 'true');

While this is perfectly functional, ServiceNow provides a much cleaner, more explicit, and frankly, more human-friendly way to achieve the same: addActiveQuery().

What is addActiveQuery()?

The addActiveQuery() method is a specialized GlideRecord method that, when called, simply adds the condition active=true to your query. It's a syntactic sugar that improves readability and reduces the chance of typos.

Why Use addActiveQuery()?

Let's be real, saving keystrokes is nice, but the benefits go beyond that:

1. Readability: inc.addActiveQuery() immediately tells anyone reading your code, "I'm looking for active records." It's self-documenting and easier to understand at a glance than inc.addQuery('active', true).
2. Conciseness: It's shorter! Less code means less to type and potentially fewer errors.
3. Reduced Typos: You're less likely to mistype active or true when using a dedicated method. ServiceNow handles the exact field name and value internally.
4. Standard Practice: It's a recognized best practice in ServiceNow development for filtering active records, making your code align with community standards.
5. Semantically Clear: It explicitly communicates intent. If a future developer sees addActiveQuery(), they instantly know the purpose.

Think of it like this: instead of saying "get me a hot beverage where the liquid is coffee," you just say "get me a coffee." It's understood that coffee is a hot beverage (usually!). Similarly, addActiveQuery() implicitly means "add the condition where the record is active."

addActiveQuery() in Action

Let's revisit some of our earlier examples, but this time, leveraging addActiveQuery().

Example 1: Active, Priority 1 Incidents

Instead of inc.addQuery('active', 'true'); inc.addQuery('priority', '1');

var inc = new GlideRecord('incident');
inc.addActiveQuery(); // Elegantly filters for active=true
inc.addQuery('priority', '1');
inc.query();
while(inc.next()){
    gs.info(inc.number + ' - ' + inc.short_description);
}
// Result: Prints all active incidents with priority 1. Clean and clear!

Example 2: Active Incidents with Priority <= 2 and 'SAP' in Short Description

This shows how well it combines with other complex `addQuery()` conditions.

var inc = new GlideRecord('incident');
inc.addActiveQuery(); // Get only active records
inc.addQuery('priority', '<=', '2'); // Priority 1 or 2
inc.addQuery('short_description', 'CONTAINS', 'SAP'); // Contains 'SAP'
inc.query();
while(inc.next()){
    gs.print(inc.number + ' - ' + inc.short_description);
}
// Result: Prints active incidents meeting all specified conditions.

The Inverse: addInactiveQuery()

Just as often as you need active records, you might need their counterparts: the inactive ones. ServiceNow provides addInactiveQuery() for this exact purpose. It's the logical opposite of addActiveQuery(), adding the condition active=false to your query.

Example: Inactive, Priority 1 Incidents

var inc = new GlideRecord('incident');
inc.addInactiveQuery(); // Filters for active=false
inc.addQuery('priority', '1');
inc.query();
while(inc.next()){
    gs.print(inc.number + ' - ' + inc.short_description + ' (State: ' + inc.incident_state.getDisplayValue() + ')');
}
// Result: Prints inactive incidents with priority 1 (e.g., closed priority 1 tickets).

Troubleshooting Common Issues with `addActiveQuery()`

While addActiveQuery() is straightforward, sometimes things don't go as planned. Here are a few common scenarios and how to troubleshoot them:

1. "It's not returning any records!"
   • Check Your Other Conditions: The most common culprit is usually another addQuery() or addEncodedQuery() that is too restrictive or incorrect, effectively canceling out your active records. Comment out other query lines and test addActiveQuery() in isolation.
   • Data Existence: Are there actually active records on the table that meet your *other* criteria? Sometimes the data just doesn't exist as you expect.
   • Permissions: Your script might not have the necessary read access to the records. Check ACLs for the user context in which the script is running.
2. "It's returning all records, not just active ones!"
   • Did you call query()?: This sounds obvious, but sometimes query() is accidentally missed after building the conditions. Without query(), next() will iterate through ALL records.
   • Is there an 'active' field?: While highly unlikely for standard ServiceNow tables, custom tables might not have an active boolean field. addActiveQuery() (and addInactiveQuery()) implicitly look for a field named active. If it's missing or named differently, these methods won't work as expected.
3. "My script runs, but prints nothing."
   • gs.print() vs. gs.info(): In certain scoped applications or newer ServiceNow versions, gs.print() might not show output in all logs. Try gs.info() for more reliable output in the logs.
   • No Matching Records: Again, the simplest explanation is often the correct one – no records match all your conditions. Use the UI to verify if records exist with the same filter logic.

When in doubt, simplify your query to its bare minimum (just addActiveQuery().query()), confirm it works, and then gradually add back your other conditions, testing each step of the way. The "Scripts - Background" module is invaluable for this iterative debugging.

Interview Relevance: Why addActiveQuery() Matters

In a ServiceNow developer interview, discussing methods like addActiveQuery() can really highlight your understanding of best practices and platform nuances. Here’s how it might come up:

• "What's the difference between addQuery('active', true) and addActiveQuery(), and why would you choose one over the other?"
  
  Your Answer: Emphasize readability, conciseness, and following established ServiceNow patterns. Explain that while both achieve the same result, addActiveQuery() is more idiomatic and less prone to typos, making the code cleaner and easier to maintain for other developers.
• "Describe a scenario where you would use addActiveQuery()."
  
  Your Answer: Provide a real-world example: "When fetching all open incidents for a dashboard widget," or "Retrieving a list of active users who belong to a specific group for an email notification."
• "How do you ensure the performance of your GlideRecord queries?"
  
  Your Answer: Mention using targeted queries (like addActiveQuery() and others) to retrieve only necessary data, avoiding gr.setLimit() when possible (but using it when only a few records are needed), and the importance of appropriate indexing on query fields. You could also briefly touch upon avoiding nested GlideRecord queries in loops.

Wrapping It Up

So there you have it! addActiveQuery() might seem like a small detail, but it's these kinds of thoughtful API methods that streamline your ServiceNow development process. It promotes cleaner, more readable, and robust server-side scripts, which ultimately makes you a more efficient and effective developer.

By understanding and consistently applying methods like addActiveQuery() and its sibling addInactiveQuery(), you're not just writing code; you're writing maintainable, idiomatic ServiceNow solutions. Keep exploring the Glide API – there are always new efficiencies to discover!

Happy scripting!