CodeVerse Creatives
Esc
ServiceNow Syllabus / Module 17 of 25 / Week 17

Week 17: CMDB & Discovery Fundamentals

Every incident you've touched so far has had a Configuration Item field sitting quietly on the form. This week is about what that field actually points at, and why the data model underneath the whole ITSM suite is arguably as important as any single process built on top of it.

Module 17 of 25 Week 17 of 26 ~3–4 Hours Hands-on Exercise Included

By the end of this week, you'll be able to

  • Explain what a Configuration Item is and how the cmdb_ci table hierarchy is structured
  • Read and build relationships between CIs, and interpret a dependency view
  • Describe, conceptually, how Discovery populates and keeps the CMDB current
1 What Is a CI 2 cmdb_ci Hierarchy 3 Relationships & Dependency Views 4 Discovery 5 Exercise 6 Knowledge Check

1. What Is a Configuration Item?

A Configuration Item (CI) is any component of IT infrastructure or service worth tracking individually and managing the lifecycle of — a server, a network switch, a software installation, a business service itself. The Configuration Management Database (CMDB) is the collection of CI records and the relationships between them; it's the answer to "what do we actually have, and how does it all connect" that every other ITSM process quietly depends on.

2. The cmdb_ci Table Hierarchy

Like task in Week 2, cmdb_ci is a base table that specific CI types extend — a server, a database instance, and a load balancer all extend cmdb_ci (through their own intermediate tables) rather than being unrelated table designs, which is what lets generic CI-level features (like the incident form's Configuration Item reference field) work uniformly across every kind of CI.

conceptual hierarchy (simplified)
cmdb_ci
├── cmdb_ci_hardware
│   └── cmdb_ci_server
├── cmdb_ci_appl (business applications)
└── cmdb_ci_service (business services)

3. Relationships & Dependency Views

CIs connect to each other through typed Relationships (cmdb_rel_ci) — "Runs on::Runs," "Depends on::Used by," and similar pairs describing how one CI relates to another. The dependency view (available from any CI's form) renders this relationship graph visually, which is often the fastest way to answer "if this server goes down, what business services does that actually affect" — exactly the kind of question that turns an incident's blast radius from a guess into something you can see.

4. How Discovery Populates the CMDB

Manually creating every CI record by hand doesn't scale past a small environment — Discovery is ServiceNow's mechanism for automatically finding infrastructure on a network and populating (and continuously refreshing) CMDB records for it, typically via a MID Server (a small on-premises agent, covered again in Week 20) that can reach into a private network the cloud instance itself can't directly probe. This course won't configure Discovery hands-on — it requires real network infrastructure to be meaningful — but knowing conceptually that "the CMDB doesn't populate itself by magic; something has to either scan for it or a human has to enter it" is enough to reason correctly about CMDB data quality issues later.

CMDB data quality is a real, ongoing problem

A stale or incomplete CMDB — CIs that no longer exist, relationships nobody maintained — is one of the most common real-world ServiceNow pain points, precisely because keeping it accurate requires either reliable automated discovery or real organizational discipline about manual updates. It's worth knowing this going in, rather than assuming CMDB data is always trustworthy by default.

5. Hands-on Exercise

Hands-on

Model a small dependency chain by hand

Requirements:

  1. Create three CI records: a cmdb_ci_server named "APP-SRV-01," a cmdb_ci_appl named "Order Processing App," and a cmdb_ci_service named "Order Fulfillment Service."
  2. Create relationships: the application "Runs on" the server, and the service "Depends on" the application.
  3. Open the server's dependency view and confirm you can see the full chain up to the business service.
  4. Create a test incident, set its Configuration Item to the server, and note how quickly you could now identify the affected business service just from the incident form.

6. Knowledge Check

Four quick questions. Expand each to check your answer.

Q1

What is a Configuration Item, and what is the CMDB?

A Configuration Item is any component of IT infrastructure or service worth tracking and managing individually — a server, an application, a business service. The CMDB is the collection of CI records plus the relationships between them, forming the underlying "what do we have and how does it connect" data model that other ITSM processes depend on.

Q2

Why does it matter that specific CI types like cmdb_ci_server extend a common cmdb_ci base table?

It's the same extension pattern as task in Week 2 — it lets generic, CI-level features (like an incident form's Configuration Item reference field, which can point at any kind of CI) work uniformly across every specific CI type, instead of needing separate handling for servers, applications, and services.

Q3

What does a dependency view let you answer that a single CI record on its own can't?

It renders the graph of typed relationships between CIs visually, making it possible to answer questions like "if this server goes down, what business services does that affect" by tracing the relationship chain outward from one CI, rather than manually cross-referencing separate records.

Q4

Why doesn't the CMDB populate itself automatically without any tooling or process?

CI records and their relationships have to come from somewhere — either automated Discovery scanning the network (typically via a MID Server reaching into infrastructure the cloud instance can't directly probe) or manual entry with real organizational discipline to keep it current. Without one of those, CMDB data drifts stale or incomplete, which is a common real-world pain point.

← Back to Week 16 Up next Week 18 →