Linking configuration items to incidents connects your CMDB to real operational problems. You'll turn scattered incident reports into traceable system issues with proper impact visibility.
The problem with isolated incident tracking
Without CI relationships, incidents exist in a vacuum. Support agents can't see which business services are affected, managers can't identify recurring problem systems, and change teams don't know what's breaking in production. The people who suffer most are the responders — they're troubleshooting blind, reinventing context every time, and missing the patterns that would prevent future outages.
How CI relationships work
The Configuration item field on incidents is a reference to the CMDB (cmdb_ci table). When populated, it enables impact analysis showing dependent services, related changes, and historical patterns. Start by manually selecting CIs to understand the connections. Then layer on automation through business rules that map symptoms to systems, or Discovery integration that auto-populates based on monitoring alerts. The CI relationship drives everything downstream — problem identification, change impact assessment, and service availability reporting.
Building mature CI automation
Manual CI selection gets you started, but production systems need automation. Business rules can map incident categories or caller locations to likely CIs. Discovery and monitoring integrations can populate CIs automatically when alerts flow in. Advanced implementations use machine learning to suggest CIs based on description text, or workflow logic that prompts agents when obvious patterns exist. The goal is capturing the relationship without adding work for responders.
Before you start
- •itil role or higher
- •CMDB populated with relevant configuration items
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Open an incident record
Navigate to Incident > All and open an existing incident, or create a new one via Incident > Create New. The incident form must be in write mode to modify the CI field.
Locate the Configuration item field
Find the Configuration item field, typically in the Details section or main form area. This is a reference field that searches the CMDB (cmdb_ci table). If you don't see it, check that your form view includes CMDB-related fields.
The field label might show as 'CI' or 'Configuration item' depending on your form configuration.
Search and select the affected CI
Click the search icon or start typing in the Configuration item field. ServiceNow searches CI names, serial numbers, and other identifying information. Select the CI that represents the system, service, or component affected by this incident.
Search by business service name first — it's often more useful than the underlying server.
Review the impact analysis
After selecting a CI, check the Related Lists section for new tabs like 'Services' or 'Dependent CIs'. These show what else might be affected. The Impact and Urgency fields may auto-populate based on the CI's business criticality.
Verify related information updates
Look for additional context that appeared: related changes, recent incidents on the same CI, or affected user counts. This information comes from the CI's relationships in the CMDB and helps with root cause analysis.
Save the incident record
Right-click the form header and select Save, or use Ctrl+S. The CI relationship is now established and will drive impact analysis, reporting, and any automated workflows tied to CI-incident relationships.
Best practices
Link to the most specific CI that's actually broken — if an application is down, choose the application CI over the server hosting it.
Don't change a CI relationship once problem management starts unless you discover the root cause is different — it breaks trending and analysis.
Set up business rules to auto-populate common CI relationships based on assignment group or incident category — manual selection doesn't scale.
Use business service CIs over technical component CIs when the impact is service-wide — it gives better visibility to stakeholders who don't care about servers.
Validate your CI data quality before rolling out automation — garbage CIs create garbage incident relationships that confuse responders.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue