Query all CIs linked to an incident

ServiceNow's incident-CI relationship has two distinct patterns that developers constantly confuse. The cmdb_ci field holds a single "primary" CI reference, while multiple CIs are stored in the task_ci many-to-many table. Most developers try to query cmdb_ci directly for "all CIs" and miss the M2M relationship entirely. The platform doesn't automatically sync these — an incident can have a primary CI that's not in the M2M table, or M2M CIs with no primary CI set.

When to use this pattern

• Building CMDB impact analysis from incident data in server-side scripts
• Populating CI details in email notifications or business rule logic
• Validating CI relationships during incident creation or update workflows
• Synchronizing incident CI data with external ITSM tools that need complete CI context

When NOT to use this pattern

• Don't use this in client scripts — use GlideAjax to call a Script Include that does the server-side query
• Don't query task_ci inside loops over incidents — you'll create N+1 query performance problems
• Don't use this for simple CI counts — use GlideAggregate with addAggregate('COUNT') instead
• Don't use this in scheduled jobs processing thousands of incidents — batch the queries using addQuery('task', 'IN', incidentSysIds) instead

Key behaviors and gotchas

• The task_ci table extends to all task types — filter by task.sys_class_name if you need incident-specific logic
• Always check ci.isValidRecord() — deleted CIs leave orphaned task_ci records that return invalid references
• Use getRefRecord() to get CI fields in one query — don't create separate GlideRecord instances per CI
• Domain separation applies to both task_ci records and CI records — you may get partial results in domain-separated instances
• The cmdb_ci field may not appear in the task_ci results — they're managed independently by different UI components
• Performance degrades after ~100 linked CIs per incident — consider if your data model is appropriate at that scale