Why “Parent” Feels Wrong in ServiceNow CMDB (and What It Actually Means)

Pratiksha · 2 hours ago

If you’ve ever modeled services in the CMDB and paused to think:

“Why does ServiceNow call this the parent? This feels fundamentally wrong.”

You’re not alone — and you’re not wrong either.

This confusion shows up very often when modeling shared platforms, multi-tenant services, or client-specific instances, especially when following CSDM guidance.

Let’s unpack why this happens and how to think about it correctly.

The Scenario: One Platform, Multiple Consumers

Imagine a shared platform service:

Meraki (Core Platform)

Consumed by multiple client-specific services:

Meraki – UBS
Meraki – JP Morgan
Meraki – CSC

Architecturally, this feels obvious:

Meraki Core is the platform
Client services are instances or consumers

So instinctively, we think:

“Meraki Core should be the parent.”

But when we create a Depends on :: Used by relationship in ServiceNow, we see:

Meraki – UBS (Parent) depends on Meraki Core (Child)

And that’s where the discomfort begins.

The Root Cause: “Parent” Is a Misleading Term

The confusion exists because Parent / Child in ServiceNow does NOT mean hierarchy, ownership, or inheritance.

It means impact direction.

What Parent Actually Means in ServiceNow

In CMDB relationships:

Parent = the CI that is impacted
Child = the CI that causes the impact

That’s it.

So when ServiceNow says:

Parent CI depends on Child CI

It really means:

If the Child CI fails, the Parent CI is impacted

Once you internalize this, the relationship suddenly makes sense.

Why Meraki – UBS Becomes the “Parent”

Ask a single operational question:

If this CI goes down, who is impacted?

If Meraki Core goes down → Meraki – UBS is impacted
If Meraki – UBS goes down → Meraki Core is not impacted

Therefore, operationally:

Meraki – UBS depends on Meraki Core
Meraki – UBS must be the Parent (impacted service)

Even though it feels backward architecturally, it is 100% correct operationally.

Two Different Concepts That Get Mixed Up

The real problem is that we try to express two different ideas using one relationship type.

Concept	Example	Depends on :: Used by
Structural hierarchy	“UBS is an instance of Meraki”	❌ Not supported
Operational dependency	“UBS breaks if Meraki breaks”	✅ Correct

ServiceNow models dependency, not inheritance.

That’s why it feels wrong when we think in platform/instance terms.

Better Mental Model (That Actually Works)

Stop thinking in parent/child terms.

Start thinking in consumer/provider terms:

Meraki – UBS depends on Meraki Core

Consumption sits higher
Capability sits lower
Impact flows upward

The word parent is just a legacy UI label.

Why ServiceNow Still Uses the Term “Parent”

Historically, the CMDB was infrastructure-focused:

Business Service
↳ Application
↳ Server
↳ Network Device

“Parent” simply meant higher in the impact tree.
As ServiceNow evolved into service-centric modeling (CSDM, APM, ITOM), the terminology stayed — even though the meaning shifted.

Legacy term. Modern confusion.

How to Explain This to Stakeholders (Pro Tip)

Avoid the word parent entirely.

Instead, say:

“This service depends on that service”
“Impact flows upward”
“This is a shared platform, these are consumer services”

A simple line that works well in workshops:

“In ServiceNow, parent doesn’t mean owner — it means impacted.”

That usually ends the debate.

Optional: How to Reduce This Confusion Further

Depending on your use case, you can model this even more cleanly:

Option 1: Use a Technical Service

Meraki Core → Technical Service
Client services → Application Services
Relationship → Depends on :: Used by

Option 2: Use Service Offerings

Meraki → Application Service
UBS / JP Morgan / CSC → Service Offerings

This is often the cleanest model when functionality is identical but consumed by different customers.

Final Thought

If calling a consumer service the “parent” makes you uncomfortable — that’s a good sign.

It means you’re thinking like an architect, not just filling CMDB fields.

Just remember:

ServiceNow models impact, not inheritance.
The relationship is right — the label is just unfortunate.

P.S. This reflects my current understanding based on hands-on CSDM and CMDB implementations. I’d welcome any discussion, alternate perspectives, or experiences from the community.

Regards,

Pratiksha