---
sourceDocument: Brazil Enable AI
sourceDocumentLink: https://www.servicenow.com/docs/r/intelligent-experiences

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil Enable AI

ft:clusterId :

    - platai

bundleId :

    - platai

workflow :

    - Platform


---

# Configuration item relationships and Knowledge Graph

# Configuration item relationships and Knowledge Graph {#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 Configuration item relationships and Knowledge Graph

Configuration item (CI) Relationships in ServiceNow enable the Knowledge Graph to answer natural language questions about service dependencies and infrastructure topology by storing typed parent-child relationships between CIs in the CMDB.
This functionality allows users to query how services, servers, databases, and other CIs relate without manually navigating CMDB tables or writing complex queries.
Show full answer Show less  

## Enabling CI Relationships for Knowledge Graph

CI relationship support is disabled by default. To enable it, set the following system properties to **true**:

* **snkg.descriptiongeneration.enablecmdbrelci**: Enables description generation for CI relationship data.
* **snkg.query.enablecmdbrelci**: Enables querying the Knowledge Graph against CI relationship data.

After enabling, allow time for the CI relationship data to be fully indexed before running queries, as incomplete indexing may yield partial results.

## How CI Relationship Data is Stored

The CMDBRELCI table stores bidirectional relationships between parent and child CIs with a relationship type expressed as **\<parent descriptor\>::\<child descriptor\>**. For example, a relationship with Bond Trading (service) as parent and lnux100 (Linux server) as child with type "Depends on::Used by" can be interpreted as:

* Bond Trading depends on lnux100 (parent to child)
* lnux100 is used by Bond Trading (child to parent)

Queries phrased in the parent-to-child direction generally produce more reliable results.

## Knowledge Graph Support for CI Relationships

The Knowledge Graph can answer queries specifying:

* The parent CI class (e.g., service)
* The relationship direction (e.g., depends on)
* The child CI class (e.g., Linux server)

Relationships are inherited up the CI class hierarchy, enabling broader queries. For instance, a relationship defined between **service** and **linux server** also applies to the parent class **server**, allowing queries for all server types.

## Supported Query Patterns

Examples of natural language queries include:

* Which services depend on a specific Linux server?
* Which UNIX servers does a named service depend on?
* Which servers of all types does a service depend on (using class hierarchy)?
* Which databases are connected by computers?
* Multi-hop queries involving multiple CI types, such as databases running on UNIX servers connected to specific network gear.

## Unsupported Query Patterns and Alternatives

Certain query types are not supported:

* **Negation queries:** Asking for CIs with no relationships is unsupported. Instead, rephrase to ask what relationships do exist.
* **Unspecified relationship types:** Queries must specify the relationship (e.g., "depending on" rather than just "related to").
* **Skipping steps in multi-hop paths:** Queries must explicitly include intermediate CIs; do not skip steps in the relationship chain.

Understanding these limitations helps tailor your queries for more accurate Knowledge Graph results.  
Configuration item (CI) Relationships enable Knowledge Graph to answer natural language questions about service dependencies and infrastructure topology by storing typed parent-child relationships between CMDB configuration items.

The CMDB_REL_CI table stores relationships between configuration items (CIs) in ServiceNow
CMDB. Each relationship connects a parent CI to a child CI through a defined relationship type, enabling the Knowledge Graph to understand and traverse the topology of your IT environment.{#ci-relationships-knowledge-graph__ci-relationships-knowledge-graph-p-1}

CI relationship support in Knowledge Graph enables users to ask natural language questions. You can ask about how services, servers, databases, and other CIs relate to one another without writing queries or navigating CMDB tables directly.{#ci-relationships-knowledge-graph__ci-relationships-knowledge-graph-p-2}

## Enabling CI relationship for Knowledge Graph

CI relationship support for the Knowledge Graph is inactive by default. Set both of the following system properties to true to enable it{#ci-relationships-knowledge-graph__ci-relationships-knowledge-graph-p-12}
{#ci-relationships-knowledge-graph__entry__2}

| System Property | Purpose |
|-|-|
| sn_kg.description_generation.enable_cmdb_rel_ci | Enables description generation for CI relationship data |
| sn_kg.query.enable_cmdb_rel_ci | Enables Knowledge Graph querying against CI relationship data |
[Table 1. System properties for CI relationship support]

Note:  
After enabling both properties, allow time for CI relationship data to be fully indexed before running queries. Results may be incomplete until indexing is complete.

## How CI relationship data is stored

Each record in the CI relationship table represents a bi-directional relationship between two CIs. Relationships are described by a relationship type that consists of a parent to
child relationship and child to parent relationship, separated by double colons:{#ci-relationships-knowledge-graph__ci-relationships-knowledge-graph-p-3}

`<parent descriptor>::<child descriptor>`{#ci-relationships-knowledge-graph__ci-relationships-knowledge-graph-p-4}

This means every relationship can be read in two directions:{#ci-relationships-knowledge-graph__ci-relationships-knowledge-graph-p-5}

* Parent → child: read using the parent to child relationship (parent descriptor)
* Child → parent: read using the child to parent relationship (child descriptor)

For example, a record in the CI relationship table has Bond Trading (cmdb_ci_service) as the parent, lnux100 (cmdb_ci_linux_server) as the
child, and a relationship type of `Depends on::Used by`. This relationship is read as:{#ci-relationships-knowledge-graph__ci-relationships-knowledge-graph-p-6}

* Bond Trading depends on lnux100
* lnux100 is used by Bond Trading

Note:  
The direction of the relationship affects how you phrase queries to the Knowledge Graph. Parent-to-child queries (for example, "depends on") return more reliable results than child-to-parent queries (for example, "used by").

## Knowledge Graph support for CI relationships

The Knowledge Graph can answer questions about CI relationships when the query clearly specifies all three of the following:{#ci-relationships-knowledge-graph__ci-relationships-knowledge-graph-p-7}

* The class of the parent CI (for example, service)
* The relationship direction --- either the parent to child relationship or child to parent relationship (for example, depends on)
* The class of the child CI (for example, Linux server)

## Class hierarchy inheritance

When you define a relationship between two CI classes, the Knowledge Graph automatically extends that relationship to all classes higher up in the CI class hierarchy. This means users can query at a more general class level and still get results across all
matching subclasses.{#ci-relationships-knowledge-graph__ci-relationships-knowledge-graph-p-8}

For example, a relationship defined between service and linux server also applies to server, which is a parent class of Linux server in the hierarchy. Querying for servers rather than Linux servers returns results across all server subclasses --- including Linux server, windows server, UNIX server, and others.{#ci-relationships-knowledge-graph__ci-relationships-knowledge-graph-p-9}  
Note:  
If a query returns fewer results than expected, try using a broader parent class in the hierarchy (for example, "server" instead of "Linux server") to include all inherited CI types.

## Supported query patterns

The following table shows examples of queries the Knowledge Graph can answer using CI relationship data. Each query specifies a parent class, a relationship descriptor, and a child
class.{#ci-relationships-knowledge-graph__ci-relationships-knowledge-graph-p-10}
{#ci-relationships-knowledge-graph__entry__8}

| Scenario | Example Query |
|-|-|
| Service that depends on a specific Linux server | Which services depend on 'lnux100' Linux server? |
| Servers that a specific service depends on | 'Bond Trading' service depends on which UNIX server? |
| All server types a service depends on (using hierarchy) | 'Bond Trading' service depends on which server? |
| Computers connected to a database | Which databases are connected by computers? |
| Multi-hop relationship across three CI types | What database runs on UNIX server that connects to 'nc6500-a01' network gear? |
[Table 2. Supported query patterns]

## Unsupported query patterns

The following query types are not currently supported. Use the recommended alternatives to get the results you need.{#ci-relationships-knowledge-graph__ci-relationships-knowledge-graph-p-11}
{#ci-relationships-knowledge-graph__entry__21}

| Limitation | Unsupported Query | Recommended Alternative |
|-|-|-|
| Negation of a relationship | Which business capabilities have no related business applications? | Rephrase to ask for what does exist rather than what does not. |
| Unspecified relationship type | Show me services related to Linux servers. | Show me services depending on Linux servers. |
| Skipping steps in a multi-hop path | Show me servers in New York. | Show me servers in racks present in datacenters located in New York. |
[Table 3. Unsupported query patterns]