Discover CMDB
Learning Objectives
After completing this unit, you’ll be able to:
- Describe the core building blocks used to organize data in the configuration management database (CMDB).
- Identify the three primary strategies used to populate data into the CMDB.
- Explain how service graphs visualize relationships to help IT teams resolve issues and plan changes.
Learn How Data Is Organized
Now that you know what the CMDB is at a high level, let’s peel back a few layers of the onion and reveal how this data is actually organized.
First, you learn some practical definitions and then you review a few visuals from CMDB in Agentforce IT Service.
The CI Building Blocks
To keep your IT infrastructure data clean and consistent, the CMDB relies on a structured data model. Here is a breakdown of the key components you use to organize your configuration items (CIs).
Term |
Description |
Benefit |
Example |
|---|---|---|---|
CI type |
A template that specifies the structure for a specific category of assets. Think of this as a typical folder structure. |
Enforces consistency and ease of use A child CI type inherits the structure from its parent, making it easy to manage large asset categories without losing specific details. CMDB ships with over 200 out-of-the-box (OOTB) CI types that save you setup time. |
"Web Server" is a child CI type of the parent "Server." |
Component |
A special type of CI that represents a specific subelement of a larger asset. Unlike regular CIs, components cannot exist on their own; they must always be attached to a parent CI. |
Allows you to track highly granular subelements within larger assets—acting much like a related list—without cluttering your main CI hierarchy |
A specific network adapter, storage disk, or installed software that makes up a larger parent asset (like a Windows or Linux server). |
CI attribute |
A field that stores specific metadata or properties about a CI. Think of this as the details written inside the file. |
Gives your team the exact technical, functional, and ownership context they need |
Operating system, version, IP address, or MAC address. |
Attribute set |
A reusable grouping of related attributes that you can apply to multiple CI types. |
Saves time and keeps records organized into logical, easy-to-read, collapsible sections on the CI record |
Hardware: Manufacturer, model number, serial number. Software: Operating system, version, patch level. |
CI relationship |
A directional link defining how two CIs interact or depend on each other (Source or Target). This is where the filing cabinet analogy breaks down! How do you link a file, in a folder, in a drawer, to a different file in a different folder in another drawer? You don’t. |
Allows you to map real-world relationships and dependencies so you can accurately assess the blast radius of an outage or a planned change |
Several customer-facing apps that run on a Linux server. For example, Apache web servers and data quality software that run on Linux servers. Note that servers could be physical (at your corporate HQ) or virtual (on public cloud infrastructure). |
Identification rules |
These rules determine how the system uniquely recognizes a CI when new data comes in. Think of this as a switchman (or switch operator) at the railroad yard. |
Prevents duplicate records and keeps your data clean by dictating whether incoming data should update an existing CI or create a brand new one |
A rule states that any incoming data with a matching MAC address updates an existing laptop CI, while a matching application name updates a software CI. |
Notice that the CMDB structure is clearly hierarchical in nature, not just a flat or random list of items.
Explore the CI Hierarchy
To take these fairly abstract terms and put them into a practical context, check out the configuration item type manager. While this isn't a step-by-step setup badge, this screenshot gives you a great look at how CMDB managers and administrators actually define and maintain the parent and child hierarchy of CI types in Agentforce IT Service.
Notice how the hierarchy expands out. The Compute CI type sits under the broader Device category, which rolls all the way up to the broadest Base CI type. That Compute parent type has multiple specific children nested beneath it, such as Mobile Device and Server.
With this structure, your team can get incredibly specific with how data is organized. You can categorize assets into highly specific child types—like a mobile phone, a Mac host, or a Windows server—while ensuring they all automatically inherit the core attributes of a standard compute device.
Populate Your CMDB
Now that you understand the structure better, how do you actually get your data into the database? When it comes to populating your CMDB, there is no single right way or a one-size-fits-all strategy. Depending on your organization's needs, you can use a blend of three strategies.
Manual Entry
Need to quickly log a single, newly purchased router? You can easily create a new CI record manually right from the CMDB workspace by clicking the New button, and filling out fields manually.
Import (Bulk Upload)
If you are migrating off of those dreaded legacy spreadsheets, you can download a CSV template tailored to a specific CI type, populate it, and use the bulk import tool to load thousands of records at once. Bonus points: The import process does basic data validation for you!
Discovery
Automated discovery scans your networks and cloud environments, fetching data and using your identification rules to seamlessly create new or update existing CIs without human intervention. You dive deeper into discovery in the next unit.
Service Graph: The Ultimate Visual Aid
Once your CIs are loaded and your relationships are defined, you unlock one of the most powerful features in Agentforce IT Service: the service graphs.
A service graph provides a dynamic, visual representation of a CI and all of its upstream and downstream dependencies. Instead of reading through rows of data, your IT team gets an interactive, graphical web of how your systems connect. For example, a basic view of a bank's infrastructure might include services, apps, load balancers for app servers, network switches, and so on.
Even better, the service graph is context-aware. If there is an active incident 
, problem 
, or change request 
tied to any CI in that dependency chain, the map lights up with a visual icon.
If a user reports a broken web portal, a support rep can open the service graph and instantly see that a backend database server is marked with a red alert icon for an active incident—turning hours of investigative guesswork into seconds of visual clarity.
In the next unit, you dive into the ingestion engine and explore exactly how automated discovery keeps all of this data—and your service graphs—perfectly up to date.