---
sourceDocument: Brazil ServiceNow AI Platform Capabilities
sourceDocumentLink: https://www.servicenow.com/docs/r/servicenow-platform

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil ServiceNow AI Platform Capabilities

ft:clusterId :

    - platcap

bundleId :

    - platcap

workflow :

    - Platform


---

# CI relationships in the CMDB

# CI relationships in the CMDB {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) 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 ServiceNow Configuration Management Database (CMDB) tracks not only configuration items (CIs) but also the relationships between them, enabling a dynamic understanding of how components interact within your IT environment.
Relationships consist of two CIs and a relationship type, such as a server being managed by another server.
These relationships can be automatically discovered via Discovery or imported from external systems, and manually edited or created using the CI relationship editor or Unified Map in the CMDB Workspace app.
Show full answer Show less  

## Key Features

* **Dependent vs. Non-dependent Relationships:** Dependent relationships (e.g., software running on hardware) help the Identification and Reconciliation Engine (IRE) avoid CI duplicates by identifying related items. Non-dependent relationships track discovery sources and timestamps but are not used for CI identification and can be safely deleted when obsolete.
* **Relationship Sources Management:** Non-dependent relationships are recorded in the Relationship Sources table, which can be configured to track detailed information to assist in relationship lifecycle management and cleanup.
* **Common Relationship Types:** Includes key relationships such as Runs On, Contains, Depends On, Hosted On, Manages, Member Of, and Owns. These relationships define how CIs interact, depend on, or contain each other, crucial for impact analysis and service modeling.
* **Suggested Relationships:** The system maintains suggested relationship types per CI class, aiding consistent and accurate modeling by offering appropriate relationship options when creating new links between CIs.
* **Relationship Governance Rules:** These rules enforce valid and consistent relationship types and directions between specific CI classes, preventing incorrect modeling.
* **CI Relations Formatter and Relationship Editor:** The CI relations formatter in the CI form provides multiple views of CI relationships and allows launching the relationship editor to create, modify, or delete relationships.
* **Relation Qualifier:** Qualifier CIs store metadata about CI relationships, enhancing relationship context and management.
* **Security Controls:** Proper security must be applied to the CI Relationship table and the editCIRelations operation to ensure authorized access and modifications.
* **CI Relation Rollups:** Enables aggregation (sum, count, max, min, mean) of relationship data, useful for reporting and analysis.

## Practical Benefits for ServiceNow Customers

By effectively managing CI relationships in the CMDB, you gain a comprehensive, dynamic map of your IT infrastructure and services. This allows you to:

* Understand dependencies to anticipate impacts of changes or issues.
* Prevent duplicate CIs and maintain data accuracy through dependent relationships and IRE functionality.
* Leverage automated discovery and import tools to efficiently populate and maintain relationships.
* Enforce relationship standards and governance for consistent configuration modeling.
* Secure your CMDB relationships to safeguard configuration data integrity.
* Perform advanced analyses by aggregating relationship data using rollups.

Overall, mastering CI relationships empowers better configuration management, change impact analysis, and service reliability within your ServiceNow environment.  
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
{#c_CIRelationships__ul_mw3_p1x_yr}  
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
{#c_CIRelationships__ul_etp_bcx_yr}

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](https://www.servicenow.com/docs/EoEVGrLO~xYBJMyKA3cmwg "Use the relationship editor to view, create, modify, or delete CI relationships. Open the relationship editor from the CI Relations formatter.") from the CI form. As an alternative to the CI relationship editor, [Unified Map](https://www.servicenow.com/docs/FnwUemzGm30iuYx05w6NiA "The Unified Map feature displays a graphical hierarchical map of the CMDB — CIs and the connections between them. Unified Map combines some of the capabilities of Dependency Views and of Service Mapping into a single map experience.") in the [CMDB Workspace store app](https://www.servicenow.com/docs/4UDeOF7HaPGbX5PDY1l~Rg "The CMDB Workspace is an efficient, central, and modernized way for you to work. Use CMDB Workspace to search and explore the CMDB, examine health and recent activities, and access CMDB dashboards and tools to support tasks in your organization.") provides the latest functionality for editing CI relationships. For more information, see [Edit relationships in Unified Map](https://www.servicenow.com/docs/hdgnlO8ZWJi0mCymlioSaQ "Use the map editor to add a relationship between two CIs or to modify an existing relationship.").{#c_CIRelationships__p_manage_relationships}

## Dependent and non-dependent relationships {#c_CIRelationships__section_qwl_nfm_cnb}

[Dependent relationships](https://www.servicenow.com/docs/83THo_T8H61d49jA5svhQA "Service definitions consist of CI types and relationship types. Dependent relationship rules define the dependency structure of the CI types and the relationship types in these service definitions, helping in CI identification and in the construction of business service maps."),
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](https://www.servicenow.com/docs/83THo_T8H61d49jA5svhQA "Service definitions consist of CI types and relationship types. Dependent relationship rules define the dependency structure of the CI types and the relationship types in these service definitions, helping in CI identification and in the construction of business service maps.") 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.
{#c_CIRelationships__ul_hwb_l2l_cnb}

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 {#c_CIRelationships__section_h1t_cmr_rsb}

The following table contains descriptions for some key CMDB relationships.{#c_CIRelationships__table_tq1_nsr_rsb__entry__3}

| 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). |
[ ]

{#c_CIRelationships__table_tq1_nsr_rsb}
* **[Suggested class relationships](https://www.servicenow.com/docs/huHsyjPvmoiXReSCADlfNQ)**   
  The system keeps a table (Suggested Relationship \[cmdb_rel_type_suggest\]) of relationship types that are appropriate for a CI type, based on its class. You can manage suggested relationships by navigating to ConfigurationSuggested Relationships, or in the CI Class Manager.
* **[Add a suggested relationship](https://www.servicenow.com/docs/P87DhV8BrtYMl5fhgQ30Iw)**   
  Add a suggested relationship for a class. The list of suggested relationships for a class is available when you create a new relationship for a CI of that class.
* **[Relationship governance rules](https://www.servicenow.com/docs/YtGYnpSWspmbdDsgHzbPFw)**   
  Relationship governance rules is a set of relationship rules used to ensure consistency and validity in modeling relationships between configuration items (CIs) in the CMDB. Use relationship governance rules to prevent the selection of relationship types or directions that are not allowed between specific CI types.
* **[CI relations formatter](https://www.servicenow.com/docs/iIy49rEL7NQ1HNqjeqH1Ug)**   
  The default CI form includes a CI relations formatter from which you can examine a CI and its relationships in various views. From the CI relations formatter, you can also launch the CI relationship editor for the CI.
* **[CI relationship editor](https://www.servicenow.com/docs/EoEVGrLO~xYBJMyKA3cmwg)**   
  Use the relationship editor to view, create, modify, or delete CI relationships. Open the relationship editor from the CI Relations formatter.
* **[Relation qualifier](https://www.servicenow.com/docs/M5Ia9OW6dNRA1chML64Dow)**   
  A relation qualifier, which is a CI of the Qualifier \[cmdb_ci_qualifier\] type, stores important information about the CI relationships.
* **[CI relationship security](https://www.servicenow.com/docs/hmQ3rCA0kmxVf5y5U1wtUw)**   
  When applying security to CI relationships, it is important to apply the access controls both to the CI Relationship (cmdb_rel_ci) table and to create an operation editCIRelations to the \* table as well.
* **[Create a CI relation rollup](https://www.servicenow.com/docs/0qvUUwtLYSMfroHS4VtcWA)**   
  A CI relation rollup allows you to sum, count, max, min, or mean a relationship type. You can create CI relation rollups.

**Related tasks**   

* [Create a CI relation rollup](https://www.servicenow.com/docs/0qvUUwtLYSMfroHS4VtcWA "A CI relation rollup allows you to sum, count, max, min, or mean a relationship type. You can create CI relation rollups.")

*[\>]: and then


