CI relationships in the CMDB

  • Release version: Xanadu
  • Updated October 19, 2025
  • 3 minutes to read
  • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of CI relationships in the CMDB

    The Configuration Management Database (CMDB) in ServiceNow not only tracks configuration items (CIs) but also the relationships between them. Each relationship links two CIs—a parent and a child—along with a relationship type, enabling you to understand dependencies and connections across your infrastructure. Relationships can be automatically discovered through Discovery or imported, and can also be managed manually via the CI relationship editor or the Unified Map in the CMDB Workspace store app.

    Show full answer Show less

    Dependent and Non-dependent Relationships

    Dependent relationships (e.g., an application running on hardware) are crucial for the Identification and Reconciliation Engine (IRE) to identify unique CIs and prevent duplicates. These relationships should not be deleted directly. Non-dependent relationships track discovery sources and last scanned times, stored in the Relationship Sources table, and can be deleted when no longer needed. To control tracking of non-dependent relationships, you can adjust the glide.identificationengine.populatesysrelsource property.

    Key Relationship Types

    ServiceNow provides predefined relationship types commonly used in the CMDB, such as:

    • Runs on / Runs: Software running on hardware or VM.
    • Contains / Contained by: Containment relationships between CIs.
    • Depends on / Used by: Dependency indicating impact of issues.
    • Managed by / Manages: One CI managing others.
    • Hosted on / Hosts: Hosting relationships (e.g., cloud resources to data centers).
    • Members / Member of: For clusters and their nodes.
    • Additional internal-use endpoint relationships support service modeling.

    Suggested Class Relationships and Governance

    The system maintains suggested relationship types per CI class to promote appropriate modeling. These can be managed via Configuration > Suggested Relationships or the CI Class Manager. Relationship governance rules enforce valid relationship types and directions between specific CI types to maintain CMDB consistency.

    Managing CI Relationships

    • CI Relations Formatter: View CI relationships in multiple formats and launch the relationship editor.
    • CI Relationship Editor: Create, modify, or delete relationships directly from the CI form.
    • Relation Qualifier: Stores metadata about relationships using Qualifier CIs.
    • Security: Apply access controls to the cmdbrelci table and create the editCIRelations operation for comprehensive security management.
    • CI Relation Rollups: Enable aggregation functions such as sum, count, max, min, or mean on relationship types to support reporting and analysis.

    Practical Benefits for ServiceNow Customers

    Understanding and managing CI relationships in the CMDB allows you to:

    • Accurately model your infrastructure and service dependencies.
    • Prevent duplicate CIs through dependent relationship identification.
    • Maintain data integrity with governance rules and suggested relationships.
    • Visualize and edit relationships efficiently using built-in tools.
    • Implement security controls to protect relationship data.
    • Leverage relationship rollups for enhanced reporting insights.

    The CMDB, in contrast to a static asset list, helps you track not only the configuration items (CIs) within your system, but also the relationships between those items.

    A relationship in the CMDB consists of two CIs and a relationship type:
    • Parent CI
    • Child CI
    • Type of the relationship that links both CIs
    For example, in the [Server1] [Managed by] [Server2] relationship:
    • Server1 is the child CI
    • Server2 is the parent CI
    • [Managed by] is the relationship type

    For example, a web application might read data from an instance of Oracle, which in turn might depend on a piece of underlying hardware. Most CIs in a CMDB have multiple relationships to other CIs, users, and groups.

    The relationships between CIs can be automatically discovered. If you use Discovery, many relationships can be automatically loaded into the system through the discovery process. If you import your data from another system, you get some form of relationships.

    You can add to automatically discovered relationships, create relationships, or edit relationships for a CI by launching the CI relationship editor from the CI form. As an alternative to the CI relationship editor, Unified Map in the CMDB Workspace store app provides the latest functionality for editing CI relationships. For more information, see Edit relationships in Unified Map.

    Dependent and non-dependent relationships

    Dependent relationships, such as tomcat RunsOn Hardware, are used by the Identification and Reconciliation Engine (IRE) to identify dependent CIs. The IRE avoids duplicate entries of CIs into your Configuration Management Database (CMDB) by leveraging these relationships to determine if a recently discovered CI is already in the CMDB.

    For non-dependent relationships, the CMDB tracks the discovery source and the last scanned time in the Relationship Sources [sys_rel_source] table. Non-dependent relationships aren't used for CI identification, and can be deleted when no longer needed.

    To avoid burdening your IRE with excessive load, by default, the Relationship Sources [sys_rel_source] table doesn't auto-populate. If you want to track full information on non-dependent relationships, you can change the default using the glide.identification_engine.populate_sys_rel_source property.

    Dependent relationships are used for CI identification, so they shouldn't be directly deleted as they aren't tracked.

    Information in the Relationship Sources [sys_rel_source] table can be used to decide if it’s safe to delete a potentially non-dependent relationship. For example, a discovery source, which is attempting to delete a non-dependent relationship can confirm that:

    • There are no other data sources for that relationship.
    • The relationship wasn't updated for some specified length of time and therefore is no longer needed.

    When a non-dependent relationship is deleted from the CI Relationship [cmdb_rel_ci] table, all cascading corresponding records in the Relationship Sources [sys_rel_source] table are deleted.

    Key relationships

    The following table contains descriptions for some key CMDB relationships.
    Parent Child Description
    Applicative Flow To Applicative Flow From

    Connections between endpoint CIs.

    Note:
    For internal use only (service model).
    Connects to Connected by

    Network Connections between elements that are talking to each other.

    Examples: Workstation to switch, switch to switch, kubernetes workload to service.

    Contains Contained by

    Typically a containment relationship (CI to contained CI). The child CI typically has a single parent CI with this relationship type.

    Examples: Tomcat to Tomcat WAR, VMware Datacenter contains Network.

    Defines resources for Gets resources from

    Parent CI defines/gets resources from a child CI.

    Example: VMware - Resource pool gets resources from ESX Server.

    Depends on Used by Parent CI depends on child CI. Meaning that problem/change in the child CI may impact the parent CI.
    Hosted on Hosts

    Hosting relationship between an element and its host.

    Examples: Cloud resource to logical data center, k8s workload to k8s cluster.

    Implement End Point To Implement End Point From

    Endpoint to CI that exposes this endpoint.

    Note:
    For internal use only (service model).
    Manages Managed by

    Typically used where one CI manages one or more other CIs.

    Example: vCenter manages vCenter Datacenter.

    Members Member of

    Typically used with clusters where a cluster node is a member of a cluster.

    Example: ESXi Server is a member of vCenter Cluster.

    Owns Owned by Usually a containment relationship (CI to owned CI). The child CI typically has a single parent with this relationship type.
    Runs on Runs

    Typically between a CI that represents a software application, to the hosting hardware/VM.

    Example: Tomcat 'Runs on' Linux server.

    Use End Point To Use End Point From

    From the CI to an outgoing endpoint.

    Note:
    For internal use only (service model).