Understanding Relationship Levels in ServiceNow CMDB: A Real-World Example!

[Selva Arun]

Hi everyone,

I wanted to share some insights on how relationship levels work in ServiceNow CMDB, especially for those who may not be familiar with this setting and its impact on performance and visibility. The information and examples below are referenced from our production instance, specifically using the 360 Encompass application CI as a case study.

What Are Relationship Levels?

In ServiceNow CMDB, the "relationship level" setting controls how many layers of CI (Configuration Item) relationships are loaded and displayed when you view a CI. This is crucial for understanding dependencies, impact analysis, and troubleshooting, but it also has a direct effect on system performance.

Real-World Example: 360 Encompass Application

Here's how different relationship levels affect what you see for a real application in our environment:

Level 1: Foundational Infrastructure

• Focus: Immediate dependencies and hosting environments.
• Example: 360 Encompass running directly on its Microsoft IIS Server. This shows the server instance where the application is hosted.

Level 2: Detailed Component Connections

• Focus: Deeper connections, including network and configuration details.
• Example: The database server supporting 360 Encompass, VMware Distributed Virtual Port Groups, and IIS Virtual Directories.

Level 3: Intermediate Detail (with Some VMware Info)

• Focus: Broader infrastructure, including some VMware-specific details.
• Example: Network switches connecting the database server to storage, "Hosted on - VMware vCenter Datacenters."

Level 4: Extensive VMware Infrastructure (Potentially Incomplete)

• Focus: Comprehensive VMware infrastructure relationships.
• Example: Power supply for network switches, VMware Virtual Machine Instances, VMware vCenter Clusters, HPE BladeSystem Blades.
• Note: At this level, you may encounter errors like "Maximum relationship limit has been reached" or "Maximum number of queries has been reached." The data may be partial or incomplete.

Level 5: Expanded Relationships (Likely Incomplete)

• Focus: Even broader set of relationships, including resource pools.
• Example: Maintenance contract for the power supply, ESX Resource Pools, further HPE BladeSystem details.
• Critical: Level 5 is heavily constrained by system limits, making the data potentially unreliable and incomplete.

Why Does This Matter?

• Performance: Higher levels (4 and 5) can cause significant slowdowns and incomplete data, especially during large-scale discovery or impact analysis.
• Accuracy: Data at higher levels may be partial or misleading due to system constraints.
• User Experience: The default relationship level is controlled by the "ecmdb.levels" user preference. If not set personally, the system uses the "empty user" default, which can affect all users.

What We Learned

• Lower levels (1 or 2) provide much better performance and a more responsive UI.
• Higher levels may not add value if the data is incomplete or inaccurate.
• It's important to balance visibility with performance, especially for critical use cases like incident management and root cause analysis.

Final Thoughts

If you're experiencing slow performance or incomplete dependency maps in your CMDB, consider reviewing and adjusting your relationship level settings. For most environments, a lower level (such as 2 or 3) offers the best balance between visibility and performance.

Reference:

This information is based on our production instance and real application data (360 Encompass). If you have questions or want to share your own experiences, please comment below!

---

Selva Arun

ServiceNow Rising Star, 2024
ServiceNow Developer, UMass Memorial Health

[the-deep]

This is useful.

I'm writing this from memory so the details may be inaccurate...

Not specifically what your article was about but on a related topic, I used to lay out the CMDB Query Builder in a way that made sense to me:

Cloud Service Account > Logical Datacenter > Virtual Machine Instance > Windows Server > MSSQL Instance

...but found that the performance was massively better doing it the other way around.

MSSQL Instance > Windows Server > Virtual Machine Instance > Logical Datacenter > Cloud Service Account

Another limitation is that with the above laid out, everything is an INNER JOIN, so you would only have a row returned if all those relationships were in place.

ie, if you have an MSSQL Instance that is related to the host windows server, but the Windows Server was not related to a Virtual Machine Instance (perhaps cloud discovery is not working for that cloud account) then no row is returned for that MSSQL Instance.

I would like to be able to return all MSSQL instances (respecting any filter conditions) and the other fields from the other tables would be populated if that data exists, but just left blank it not, rather than just not return that MSSQL Instance at all.

[Selva Arun]

@the-deep ,

Thank you for sharing your experience and these practical insights!
You’re absolutely right—how you structure the CMDB Query Builder path can have a big impact on performance, and INNER JOINs can definitely limit your results if any relationship in the chain is missing. I’ve run into similar challenges, especially when trying to get a complete picture across hybrid or cloud environments where not all relationships are always present.

It would be great if the Query Builder supported more flexible joins (like LEFT JOINs), so we could return all primary records (like MSSQL Instances) and just leave related fields blank if the relationship isn’t there, instead of excluding them entirely. That would make reporting and analysis much more robust.

Thanks again for adding this perspective—these kinds of real-world tips are so valuable for the community!

— Selva

[the-deep]

The inner join issue can be worked around a little bit but you do end up with multiple columns for the same CI class.

For example this query shows database instances, the server they're hosted on and any associated VM's (and downstream CI's).

But the Server node hanging bottom left is necessary because without it, if the host server has no relationship to a VM for whatever reason, that database instance would not appear in the results. Similarly the Virtual Machine instance.