CMDB Architecture, CI Classes & CSDM
The CMDB is not just a database — it's a governed model with a defined class hierarchy, a Common Service Data Model (CSDM) for consistent naming, Dynamic CI Groups for flexible scoping, and a Build domain for SDLC. These fundamentals underpin every other CMDB topic.
cmdb_ci root table and table
inheritance; every CI class in this topic is a Part 1 table that extends
cmdb_ci. (2) Part 3 (Discovery) — Discovery creates
CI records in these classes; the class hierarchy determines which table each discovered
device lands in (e.g. cmdb_ci_server for a server). (3) Part 4
(IRE) — IRE identification rules are keyed to these exact class names. This
topic is also the foundation for all Part 5 Topics 2–8 (relationships, CSDM, CI Class
Manager, health, and service modeling).
The CI Class Hierarchy
Every Configuration Item in ServiceNow lives in a table that extends cmdb_ci. This is not just a naming convention — it's the inheritance chain that gives every CI its base set of fields: name, sys_class_name, managed_by, owned_by, support_group, operational_status, and more.
When Discovery finds a server, it creates a record in cmdb_ci_server.
That table extends cmdb_ci_hardware, which extends
cmdb_ci. The record physically exists in cmdb_ci_server
but is also visible in the parent tables via ServiceNow's single-table inheritance.
├─ cmdb_ci_hardware (serial_number, manufacturer, model)
│ ├─ cmdb_ci_computer (cpu_count, ram, disk_space)
│ │ └─ cmdb_ci_server (virtual, cluster_node)
│ └─ cmdb_ci_network_adapter
├─ cmdb_ci_service (business services)
│ └─ cmdb_ci_application_server
└─ cmdb_ci_appl (software applications)
└─ cmdb_ci_db_instance
sys_class_name field.
A query on cmdb_ci returns all CIs from all child tables — ServiceNow's
ORM flattens the hierarchy. A query with sys_class_name=cmdb_ci_server
returns only server records. This is why filtering by class is so important in
CMDB queries — without it you get thousands of mixed CI types.
cmdb_ci_server record IS a cmdb_ci record — it inherits
all base fields. But a query on cmdb_ci without a class filter returns
all CI types, not just base CIs. This distinction matters when writing
Transform Maps — if your target table is cmdb_ci but you want to create
servers, you must use cmdb_ci_server as the target (or use a Service Graph
Connector which handles class targeting for you).
CSDM — Common Service Data Model
The Common Service Data Model (CSDM) is ServiceNow's prescriptive framework that defines how to model your IT and business services in the CMDB. Think of it as a blueprint that tells you what tables to use, what fields matter, and how different CI types relate to each other. It's not a plugin — it's a recommended approach and naming standard.
The CSDM organizes the CMDB into domains, each representing a different layer of IT architecture:
| CSDM Domain | What It Models | Key Tables |
|---|---|---|
| Foundation | Locations, companies, departments, people | cmn_location, core_company, sys_user_group |
| Manage Technical Services | Physical and virtual hardware, network | cmdb_ci_server, cmdb_ci_network_gear |
| Manage Applications | Software instances, databases, middleware | cmdb_ci_appl, cmdb_ci_db_instance |
| Sell/Consume Services | Business and IT Services visible to end-users | cmdb_ci_service, service_offering |
| Design | Service models, Application Services in design | cmdb_ci_service_auto, cmdb_ci_app_server |
| Build & Integrate | SDLC artifacts — code repos, CI/CD pipelines, build jobs | cmdb_ci_sdlc_build_tool, cmdb_ci_sdlc_pipeline |
Information Objects
An Information Object is a CSDM concept — it's a high-level category that groups related CI types together under a common business meaning. Rather than thinking about specific tables, the CSDM presents them as meaningful objects like "Application" or "Service" that business and IT people both understand.
For example, the Application Information Object encompasses:
cmdb_ci_appl— Application CI (the installed software)cmdb_ci_application_server— the server hosting the app- Application Services that expose the app's capabilities
Information Objects are the CSDM's way of saying "here is a meaningful unit of IT that has a business name, technical components, and relationships." They appear in CMDB Workspace and CSDM documentation as the navigational anchors.
Build & Integrate Domain — SDLC in the CMDB
One of the less-known CSDM domains is Build & Integrate, which models Software Development Lifecycle (SDLC) artifacts as CIs in the CMDB. This allows organizations to track the relationship between code repositories, build pipelines, artifacts, and the running applications they deploy.
The key insight is that a running application (a CI in cmdb_ci_appl)
was built from source code (tracked in an SDLC CI). By modeling this in the CMDB,
you can trace: "This production outage was caused by a change to the payment service,
which was deployed by pipeline run #482 from commit abc123 in repo payment-api."
SDLC CI Classes in the Build Domain
When an Application Service is deployed via a pipeline, a relationship is created
between the cmdb_ci_sdlc_artifact and the deployed cmdb_ci_appl CI.
This is how CSDM links the "Build" domain to the "Application" domain.
cmdb_ci child tables,
not in separate application tables. This means they have IRE identification rules,
participate in CMDB Health scoring, and can have relationships (cmdb_rel_ci) to
other CIs. Don't confuse "SDLC artifacts" with ServiceNow's Application table
(sys_app) — that's for ServiceNow apps, not your customer's software.
Dynamic CI Groups
A CI Group is a named collection of Configuration Items. Groups let you define a set of CIs that can be used together for change management scope, reporting, service mapping, or maintenance windows.
There are two types:
| Type | How Members Are Defined | Membership Updates | Use Case |
|---|---|---|---|
| Static CI Group | Admin manually adds specific CI records to the group | Manual only — must add/remove members explicitly | Small, stable sets (e.g., "The 3 DNS servers") |
| Dynamic CI Group | Defined by an encoded query or filter condition that runs against the CMDB | Automatic — membership recalculated each time the group is evaluated | Large or changing sets (e.g., "All Linux servers in Data Center East") |
Why Dynamic CI Groups Matter
Imagine you manage 200 Linux servers and need to apply a maintenance window every Tuesday. With a Static group, you'd have to manually add/remove servers every time one is provisioned or decommissioned. With a Dynamic group, you define the query once — class=cmdb_ci_server AND os CONTAINS linux AND location=DC-East — and the group automatically includes all matching CIs as they change.
- Dynamic CI Groups are stored in
cmdb_ci_query_based_serviceor similar CMDB group tables - The query is evaluated at use time — no pre-computed list is stored permanently
- Can be used in Change Management scope, CMDB Health scoring inclusion rules, and Service Maps
Application Services
An Application Service is a special CMDB CI type
(cmdb_ci_service_auto) that represents a running application and all the
CIs that support it. Unlike a static list of related CIs, an Application Service
is a live, dynamic map of infrastructure components.
Application Services are the bridge between the technical CMDB and the business view. Incident management asks "what services are affected?" — the Application Service answers that by showing which CIs run the service and their current health.
Manual vs. Auto-Discovered Application Services
- Manually created — Admin defines the Application Service and manually adds CIs to it. Reliable but labor-intensive and quickly goes stale.
- Discovery-populated — Service Mapping (a separate ServiceNow app) crawls network traffic and dependency data to automatically populate the Application Service CI map. Most accurate but requires Service Mapping license and Discovery.
- Tag-based — CI attributes or tags define membership rules. Hybrid between manual and dynamic.
cmdb_ci_service) is what business users see —
"Email Service," "HR Portal." It's a high-level grouping visible in the Service Catalog.
Application Service (cmdb_ci_service_auto) is the technical
implementation — all the servers, databases, and network components that make the
Business Service work. Business Services contain Application Services in the CSDM model.
CMDB Classes Quick Reference
The exam tests your ability to identify the correct CI class for a given scenario. Here are the most commonly tested class mappings:
| Scenario | CI Class | Parent Chain |
|---|---|---|
| Physical server in data center | cmdb_ci_server | → cmdb_ci_computer → cmdb_ci_hardware → cmdb_ci |
| Virtual machine (VMware VM) | cmdb_ci_vm_instance | → cmdb_ci_computer → cmdb_ci_hardware → cmdb_ci |
| Database instance (SQL Server) | cmdb_ci_db_instance | → cmdb_ci_appl → cmdb_ci |
| Network switch / router | cmdb_ci_netgear (or cmdb_ci_ip_router) | → cmdb_ci_hardware → cmdb_ci |
| Software application | cmdb_ci_appl | → cmdb_ci |
| Business Service (e.g. "Email") | cmdb_ci_service | → cmdb_ci |
| Running application service map | cmdb_ci_service_auto | → cmdb_ci_service → cmdb_ci |
| Code repository (Git) | cmdb_ci_sdlc_repository | → cmdb_ci |
| CI/CD pipeline | cmdb_ci_sdlc_pipeline | → cmdb_ci |
Common Exam Traps — CMDB Architecture, CI Classes & CSDM
- All CI tables extend
cmdb_ci— queryingcmdb_cireturns ALL CI types sys_class_namestores the exact CI class for every record — use it to filter by type- CSDM is a prescriptive standard/model, not a plugin — deviating breaks Discovery and IRE mappings
- Information Objects = CSDM conceptual groupings (e.g., "Application") that map to multiple tables
- Build & Integrate domain models SDLC artifacts (repos, pipelines, build tools) as CIs
- SDLC CIs are in
cmdb_cichild tables — they participate in IRE and CMDB Health like any CI - Dynamic CI Group = query-based membership evaluated at use time, not a stored list
- Dynamic group membership does NOT update in real time — it re-evaluates when the group is queried
- Business Service (
cmdb_ci_service) = high-level user-facing; Application Service (cmdb_ci_service_auto) = technical map
Practice Questions
4 questions · Select an answer to see the explanation immediately.
A developer writes a report against the cmdb_ci table. Which CI records will the report return?
B is correct. In ServiceNow's table inheritance model, all CI class tables (cmdb_ci_server, cmdb_ci_linux_server, cmdb_ci_network_adapter, etc.) extend cmdb_ci. Querying cmdb_ci returns ALL CI records from all child tables. This is why cmdb_ci is the "universal" starting point for cross-class CI reports. To filter by type, use the sys_class_name field which stores the exact CI class for every record.