CI Relationships & Dependency View
CI Relationships connect CIs to model real-world dependencies. The Dependency View and Unified Map visualize these connections — telling you which CIs are upstream (what your CI depends on) and downstream (what depends on your CI).
cmdb_rel_ci is a many-to-many join table — exactly the pattern covered in
Part 1 Topic 3 (Relationships & Database Views). If the concept of a
self-referential M2M table feels unfamiliar, review that topic first. Part 5 Topic
1 (CI class hierarchy) is the other prerequisite: both the parent and
child columns in cmdb_rel_ci are references to cmdb_ci
— the root class from Topic 1. CI Relationships are also what CSDM service modeling (Part 5
Topics 6–7) uses to link Business Applications to Technical Services to Infrastructure CIs.
The cmdb_rel_ci Table
CI Relationships in ServiceNow are stored in the cmdb_rel_ci
table — a self-referential many-to-many (M2M) table where both parent and child
reference cmdb_ci. This design means any CI can be related to any other CI.
cmdb_rel_ci table is
the list of all train routes — each row says "City A connects to City B, and the
type of route is 'Express'." Without this table, the cities exist but you can't
know which are connected or how. The Dependency View draws the map visually.
cmdb_rel_ci Key Fields
| Field | Type | Meaning |
|---|---|---|
| parent | Reference → cmdb_ci | The CI that depends on the child (the "from" end) |
| child | Reference → cmdb_ci | The CI being depended on (the "to" end) |
| type | Reference → cmdb_rel_type | The relationship type (e.g., "Runs on", "Connected by") |
The cmdb_rel_type table defines available relationship types. Each type has an outbound descriptor (how the parent relates to the child) and an inbound descriptor (how the child relates to the parent). For example, the "Runs on" type: parent "Runs on" child, and child is "Used by" parent.
Upstream vs. Downstream
Understanding direction is crucial for impact analysis. When an incident affects a CI, you need to know which services and users are impacted (downstream) and what infrastructure components could have caused the issue (upstream).
Upstream of App Server Downstream of App Server
→ App Server "Runs on" Database Server (DB is upstream)
→ Web Frontend "Depends on" App Server (Web is downstream)
Definitions
- Upstream CIs — CIs that the selected CI depends on. If an upstream CI fails, the selected CI may fail. Example: The App Server's upstream is the Database Server it queries.
- Downstream CIs — CIs that depend on the selected CI. If the selected CI fails, downstream CIs are impacted. Example: The App Server's downstream is the Web Frontend that calls it.
Dependency View
The Dependency View is a visual graph that opens from any CI record. It shows the selected CI at the center with its related CIs branching outward by relationship type. You can expand each branch to follow the dependency chain.
To open: navigate to any CI record → click the Dependency Views related list → choose a saved view (or use the icon in the CI header).
What You Can Do in Dependency View
- Expand/collapse — click any CI node to show its relationships
- Filter by relationship type — show only "Runs on" or only "Connected by" relationships
- Highlight impact — trace downstream to identify affected services
- Open CI records — double-click any node to open the CI record in a new tab
- Show CI details — hover over a node to see class, status, and key attributes
cmdb_rel_ci.
It does NOT show reference field relationships (like "assigned_to") or table hierarchy
relationships (parent/child class). If you want to show that Server A "Runs" Application B,
you must create a relationship row in cmdb_rel_ci — a reference field pointing
from one CI to another is NOT enough to appear in Dependency View.
Unified Map
The Unified Map (also called Service Map) is an enhanced visualization that goes beyond the individual CI view. While Dependency View is CI-centric, Unified Map is service-centric — it starts from a Business Service or Application Service and shows the full infrastructure dependency map for that service.
The Unified Map is the primary tool for:
- Service impact analysis — when an incident is raised against a CI, which business services are affected?
- Change impact assessment — before approving a change to a server, see all services that depend on it
- Root cause navigation — follow the graph upstream from an impacted service to find the failing CI
Layers in the Unified Map
| Layer | What It Shows |
|---|---|
| Business Services | Top-level services visible to business users (Email, HR Portal) |
| Application Services | Technical implementations powering Business Services |
| Application Tier | Application servers, web servers, middleware |
| Database Tier | Database instances and servers |
| Infrastructure Tier | Physical/virtual servers, storage, network |
cmdb_rel_ci.
If Discovery hasn't run Service Mapping, or if relationships weren't created during
import, the map will be incomplete. A CMDB with poor relationship coverage will show
isolated nodes with no connections — the map is a diagnostic for relationship data quality.
Common Relationship Types
The exam tests which relationship type to use for given scenarios. These are the most commonly tested:
| Relationship Type | Outbound (Parent → Child) | Inbound (Child → Parent) | Example |
|---|---|---|---|
| Runs on | Runs on | Hosts | Application "Runs on" Server |
| Depends on::Used by | Depends on | Used by | Service "Depends on" Database |
| Connected by | Connected by | Connects | Server "Connected by" Switch |
| Members of | Members of | Contains | VMs "Members of" Cluster |
| Virtualized by | Virtualized by | Virtualizes | VM "Virtualized by" Hypervisor |
| Uses::Used by | Uses | Used by | App "Uses" Shared Library |
cmdb_rel_ci, the parent field is the CI that "does" the
relationship (e.g., the Application that "Runs on" the Server). The child
is the target. This can be counterintuitive: the Application (parent) runs on the
Server (child) — but in physical terms, the Server is the foundation. Think of parent/child
as "who initiates the relationship," not who is physically on top.
Common Exam Traps — CI Relationships & Dependency View
- All CI relationships stored in
cmdb_rel_ci(M2M table with parent, child, type) - Dependency View only shows
cmdb_rel_cidata — reference fields don't appear there - Upstream = what a CI depends on; Downstream = what depends on the CI
- Impact propagates downstream; root cause analysis goes upstream
- Unified Map is service-centric (starts from Business/Application Service); Dependency View is CI-centric
- In
cmdb_rel_ci: parent "does" the relationship to child (App parent "Runs on" Server child) - Relationship type is in
cmdb_rel_type— has outbound and inbound descriptors - Map quality depends entirely on relationship completeness — missing relationships = disconnected nodes
Practice Questions
4 questions · Select an answer to see the explanation immediately.
A server CI has its assigned_to field pointing to a technician's User record. Will this relationship appear in the Dependency View?
B is correct. Dependency View reads exclusively from the cmdb_rel_ci table (the Many-to-Many relationship table with parent, child, and type columns). Reference fields (like assigned_to, managed_by, owned_by) are regular database foreign keys but are NOT stored in cmdb_rel_ci. To show a "CI managed by person" relationship in Dependency View, you must create a row in cmdb_rel_ci — a reference field alone is insufficient.