Query incidents using addQuery with IN operator

The IN operator in ServiceNow queries expects a comma-separated string, not an array. Most developers stumble when converting arrays of sys_ids into this format—they miss that empty strings or null values in the list will cause the query to behave unexpectedly, often returning no results when it should. The platform doesn't automatically filter these out, so you must sanitize your input array before joining it.

When to use this

• Batch lookups after collecting sys_ids from another query or user input
• Filtering by specific state values when you need multiple states like active incident statuses
• Processing records where a choice field matches several predetermined values
• Script Includes or Business Rules where you control the input data and list size

When NOT to use this

• Don't use with uncontrolled list sizes—IN queries with hundreds of values perform poorly. Use setLimit() and batch processing instead
• Don't use in client scripts—the query runs server-side anyway. Use GlideAjax to call a Script Include instead
• Don't use when you only need counts or aggregates—use GlideAggregate with IN instead of fetching full records
• Don't nest this inside loops over other GlideRecord queries—you'll create N+1 query problems

Key behaviors and gotchas

• Empty strings or null values in your comma-separated list will cause the entire IN condition to malfunction—always filter them out first
• State values must be integers (1,2,3) not strings ('New','In Progress')—the database stores choice values as numbers
• Reference fields like assignment_group expect sys_ids, not display values
• ACLs still apply—records will be silently filtered from results based on the current user's permissions
• Performance degrades significantly with more than 50-100 values in the IN list, especially on non-indexed fields
• Domain separation applies—cross-domain records won't appear unless you're in the global domain or have proper visibility