CI relationships document how your infrastructure components depend on each other — which servers host applications, which services rely on databases, which networks connect systems. You'll create these relationships and use dependency maps to visualize the connections.
Why CI relationships matter for operations
Before you document CI relationships, impact analysis is guesswork. When a database server goes down, you're scrambling to figure out which applications break and which teams to notify. Change managers approve risky changes because they can't see downstream dependencies. Incident responders waste time discovering connections during outages instead of knowing them upfront. The people who feel this pain most are operations teams, service owners, and anyone trying to assess change impact or troubleshoot cascading failures.
How ServiceNow stores and displays relationships
CI relationships are directional parent-child connections stored in the cmdb_rel_ci table. The key relationship types are 'Depends on' (service depends on database), 'Hosted on' (application hosted on server), and 'Runs on' (service runs on infrastructure). You create these from any CI record using the CI Relationships related list, where you pick the related CI and relationship type. ServiceNow automatically creates the inverse relationship — if Server A hosts Application B, then Application B runs on Server A. Start with your most critical services and work backwards to their dependencies.
Building comprehensive dependency maps
Once you have basic relationships documented, use the Dependency View to visualize connection chains and spot gaps. Add business service relationships to connect technical CIs to business impact. Configure relationship rules to auto-create standard relationships when CIs are discovered or created. Set up health state propagation so parent CI outages automatically affect child CIs. The difference between basic relationships and production-quality dependency mapping is coverage — you want enough relationships that the dependency view actually helps during incident response.
Before you start
- •itil role or equivalent access to CMDB records
- •Both CIs must already exist in the CMDB
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 the parent CI record
Navigate to Configuration > Base Items > Configuration Items and search for the CI that will be the parent in the relationship. Open its record. The parent is typically the supporting component — the server, database, or infrastructure that the child depends on or runs on.
If you're documenting 'Application A depends on Database B', then Database B is the parent CI you want to start from.
Access CI Relationships related list
Scroll down to the CI Relationships related list. If you don't see it, click the paperclip icon to configure related lists and add it. This related list shows all existing relationships where this CI is either the parent or child.
Create new relationship record
Click New in the CI Relationships related list. The Parent field will auto-populate with your current CI. In the Child field, search for and select the CI that depends on, runs on, or is hosted by the parent CI.
Set the relationship type
In the Type field, choose the appropriate relationship: 'Depends on::Depends on' for service dependencies, 'Hosted on::Hosted on' when one CI physically contains another, or 'Runs on::Runs on' when software executes on hardware. The format shows 'Parent perspective::Child perspective' — ServiceNow will create both directions automatically.
Use 'Depends on' for logical dependencies and 'Runs on' for software-to-hardware relationships — 'Hosted on' is mainly for physical containment.
Add connection details
Fill in Connection strength (typically 'Weak', 'Medium', or 'Strong' based on how critical the dependency is) and add any relevant notes about the relationship. Set the Connection strength to 'Strong' for dependencies that would cause immediate service failure. Click Submit to save the relationship.
Verify the inverse relationship
Navigate to the child CI's record and check its CI Relationships related list. You should see the inverse relationship automatically created. For example, if you created 'Database hosts Application', the application record will show 'Application runs on Database'.
View in dependency map
Return to either CI record and click the Dependency View related link (or navigate to Configuration > Dependency Views > View CI Dependencies). Enter one of your CIs to see the relationship visualized as connected nodes. Use the depth controls to show multiple levels of dependencies.
Best practices
Document relationships from the business service level down to infrastructure — partial relationship mapping is worse than none because it creates false confidence during impact analysis.
Use 'Depends on' for service-to-service relationships and 'Runs on' for application-to-infrastructure — mixing these types makes dependency views harder to interpret.
Set Connection strength accurately because many impact analysis tools use this to determine which relationships matter during outages.
Don't create relationships for temporary dependencies like patching or maintenance windows — these clutter the permanent dependency view.
Validate your relationships periodically using the Dependency View — if the visual map doesn't match what operations teams know about the infrastructure, fix the relationships.
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