Query all active incidents using GlideRecord

The addActiveQuery() method is not just a convenience wrapper — it's the only reliable way to query for active records in ServiceNow. Using addQuery('active', true) will break in instances where custom state values exist or where the active field behavior has been modified. The platform maintains internal logic about what constitutes an 'active' record that goes beyond a simple boolean check, and addActiveQuery() encapsulates this complexity correctly.

When to use this pattern

• When processing incidents in Business Rules or Script Includes where you need field values from multiple columns
• When the result set is bounded (under 1000 records) and you control the query filters
• When you need to perform operations on each record individually in server-side scripts
• When building scheduled jobs that process active incidents in batches with proper ordering

When NOT to use this pattern

• Don't use this in client scripts — use GlideAjax to call a server-side Script Include instead
• Don't use this when you only need a count of active incidents — use GlideAggregate with addAggregate('COUNT')
• Don't use this inside a loop over another GlideRecord — you'll create N+1 query performance problems
• Don't use this for large datasets (>1000 records) without setLimit() — use GlideRecordSecure with pagination instead

Key behaviors and gotchas

• For incidents, addActiveQuery() excludes state values 6 (Resolved), 7 (Closed), and 8 (Canceled) — not just active != true
• Always use hasNext() before next() to handle empty result sets — while(gr.next()) works but doesn't let you handle zero results explicitly
• Use getValue() for state integers and sys_ids, getDisplayValue() for human-readable names and dates
• Reference fields return empty string when null, not null — check with gr.getValue('assigned_to').nil() not == ''
• ACL restrictions apply to GlideRecord queries — users will only see incidents they have read access to, even in Business Rules
• Domain separation automatically applies — queries will be scoped to the current user's domain unless you use setWorkflow(false)