Query incidents by assignment group

The critical insight here is that assignment groups are referenced by sys_id, not display name. Most developers instinctively try to query by group name first, which fails in enterprise instances where group names aren't unique across domains. Always use the sys_id from the sys_user_group table, and the platform handles domain separation automatically. The assignment_group field is indexed and reference-qualified, making this pattern performant even on millions of records.

When to use this pattern

• Business Rules that need to process all incidents for a specific team during record updates
• Scheduled Jobs that generate group-specific reports or notifications
• Script Includes that implement group-based workflow logic where you need field values from multiple columns
• Fix Scripts for data cleanup operations scoped to specific assignment groups

When NOT to use this pattern

• Client Scripts — use GlideAjax to call a Script Include that runs this server-side
• When you only need counts or aggregations — use GlideAggregate instead
• Inside loops over other GlideRecord queries — you'll create N+1 performance problems
• For real-time UI components — use REST Table API or GraphQL instead

Key behaviors and gotchas

• State values are integers: '1' (New), '2' (In Progress), '6' (Resolved), '7' (Closed) — never use display values
• The assignment_group field is indexed and performs well, but combining with non-indexed fields kills performance
• ACLs apply to the query results — users will only see incidents they have read access to
• Use hasNext() before looping — empty result sets are common and next() on empty sets returns false
• Domain separation automatically filters results to the user's domain when the assignment group has domain restrictions
• Always order results with orderBy() — database order is unpredictable without explicit sorting