⬡ Part 5 · Topic 6

CSDM Framework — The Common Service Data Model Explained

You've learned how CIs are captured, stored, and organized in the CMDB. But a CMDB full of servers and applications doesn't automatically tell you how they connect to the business — which services they support, who owns them, and how they deliver value. The Common Service Data Model (CSDM) is ServiceNow's framework for answering those questions. It's a prescribed way of modeling IT services from the business perspective down to the infrastructure.

📋 9 sections ⏱ ~35 min read 🎯 ~11% exam weight (CSDM domain) 🏷 CSDM · Business Capability · Business Application · Technical Service

🔗

Builds On This topic assumes you understand three prior concepts: (1) CI class hierarchy from Part 5 Topic 1 — CIs extend cmdb_ci into specific classes like cmdb_ci_server; (2) Service Mapping from Part 3 Topic 4 — Service Mapping discovers application infrastructure and creates Application Services (cmdb_ci_service_auto); (3) CI relationships from Part 5 Topic 2 — cmdb_rel_ci links CIs together. CSDM builds on all three to create a business-to-infrastructure chain.

Section 1

The Business-to-Infrastructure Gap That CSDM Bridges

Imagine a critical incident: your email system is down. From the business perspective, "email is down" — that's all the executives know. But in the CMDB, the actual failure might be a load balancer CI in the network tier, a database CI in the data tier, or an application server CI in the application tier.

Without CSDM, these two views — "email is a business service" and "load balancer LB-PROD-01 is down" — exist in separate mental models. Incident responders must manually figure out which infrastructure CIs support "email." This takes precious time during an outage.

CSDM creates a structured, machine-readable map from business services down to infrastructure CIs. When LB-PROD-01 has an incident, the system automatically knows it affects the Email business application, which affects the Communications business service, which is owned by the HR department.

🏗️

Analogy — CSDM as an Org Chart for IT Services A company has an organizational chart: CEO → VP of Sales → Regional Manager → Sales Rep. Each person is a "CI" (a person with attributes). But the org chart shows how they relate to the company's business functions. CSDM is the org chart for IT: Business Capability → Business Application → Technical Service → Application Service → Infrastructure CIs. Without the chart, you have a list of people (CIs) with no context. With the chart, you understand how each person (CI) contributes to the company's outcomes.

Section 2

CSDM's Four Domains — The Layered Model

CSDM organizes IT data into four domains, arranged from business-level at the top to infrastructure at the bottom. Each domain is a distinct layer, and the layers are connected by relationships.

Domain 1: Business

Business Capability · Business Application · Business Process · Product

Answers: What does the business do? What business outcomes does IT enable?

↕

Domain 2: Design

Application Service · Business Service · Service Offering · Service Commitment

Answers: What IT services exist? What do we promise to deliver and to whom?

↕

Domain 3: Manage

Technical Service · Software Product · Vendor · Contract

Answers: What IT components/services need to be managed operationally?

↕

Domain 4: Build/Sell/Support (CMDB CIs)

Server, Network Device, Database, Application Instance, Cloud Resource

Answers: What infrastructure exists? What can be discovered, tracked, and monitored?

The power of CSDM is in these connections between layers. A CI in Domain 4 (a specific Linux server) is linked upward to a Technical Service (Domain 3), which is linked to an Application Service (Domain 2), which is linked to a Business Application (Domain 1). This chain allows ServiceNow to automatically determine business impact when any CI fails.

💡

Key Concept — CSDM Is Prescriptive, Not Custom CSDM is a specific, opinionated framework published by ServiceNow. It defines exactly which CI classes should represent each concept (e.g., Business Application must be cmdb_ci_business_app) and exactly how they should be related. Organizations that don't follow CSDM create their own ad-hoc models that don't benefit from ServiceNow's built-in workflows, reports, and impact analysis.

Section 3

Domain 1 — The Business Layer

The Business domain captures what the business does and what IT enables. These are high-level concepts that business stakeholders (executives, product managers) recognize and own.

CSDM Concept	CI Class	Plain English Explanation	Example
Business Capability	cmdb_ci_business_capability	A core thing the business can do. Not a specific tool — the capability itself.	"Process Customer Orders", "Manage Payroll", "Conduct Fraud Detection"
Business Application	cmdb_ci_business_app	A named software application that the business uses to support a capability. Business users identify it by name.	"Salesforce CRM", "SAP ERP", "Custom Expense Reporting App"
Business Process	cmdb_ci_business_process	A defined set of steps the business follows. Can cross multiple applications.	"Order-to-Cash Process", "Employee Onboarding Process"
Product	cmdb_ci_product	A product or service the company offers to external customers.	"Online Banking App", "Premium Insurance Plan"

⚠

Exam Trap — Business Application Is Not a Technical Application In CSDM, "Business Application" (cmdb_ci_business_app) is a business-level concept — it's the name stakeholders use (e.g., "our HR system"). It's NOT the same as an application server CI or software CI in Domain 4. A Business Application is linked DOWN to Domain 2 (Application Services) which are then linked down to Domain 3 and 4 (infrastructure). Don't confuse the two.

Section 4

Domain 2 — The Design Layer (Services)

The Design domain captures what IT services exist, what they promise to deliver, and how they're structured technically. This is where IT service management meets the CMDB.

CSDM Concept	CI Class	Plain English Explanation
Application Service	cmdb_ci_service_auto	A technical implementation of an application as a running service. Contains the actual server/database CIs that make it run. Discovered by Service Mapping (Part 3). Note: CSDM 5 (Zurich+) renamed this to "Service Instance."
Business Service	cmdb_ci_service_business	A grouping of Application Services that together deliver a business outcome. This is the IT perspective on a Business Application.
Service Offering	cmdb_ci_service_offering	What the IT organization formally offers to its customers. Tied to a Service Commitment (SLA).
Service Commitment	cmdb_ci_commitment	The formal SLA or OLA that defines the quality promise (availability, response time) for the service offering.

The Application Service — CSDM's Critical Junction

The Application Service is the most important CSDM object for the CIS-DF exam. It sits at the junction of business and infrastructure — it connects upward to Business Applications and downward to the actual server, network, database CIs.

An Application Service is populated by Service Mapping (covered in Part 3 Topic 4). When Service Mapping runs, it discovers all the CIs that make up an application and creates an Application Service CI with those CIs as members (via cmdb_rel_ci relationships).

Section 5

Domain 3 — The Manage Layer (Operations)

The Manage domain captures the IT components and vendor relationships that need operational management. This layer is between the service definitions (Domain 2) and the raw infrastructure (Domain 4).

CSDM Concept	CI Class	Plain English Explanation
Technical Service	cmdb_ci_service_technical	A specific technical capability used internally by IT — like "Database Platform" or "Load Balancing Service." Not visible to business users, but fundamental to Application Services.
Software Product	cmdb_ci_software_product	A specific software product (like Oracle Database 19c or Apache Tomcat 9) tracked for licensing, version management, and support lifecycle.
Vendor	core_company (with vendor=true)	The organization that provides a software product or hardware component.
Contract	ast_contract	The formal agreement with a vendor — licenses, support terms, renewal dates.

💡

Key Concept — Technical Service vs. Application Service Technical Service (Domain 3): An internal IT shared service used by other services. Example: "Oracle Database Platform" is a Technical Service that the HR Application Service, the Finance Application Service, and the CRM Application Service all depend on. Application Service (Domain 2): A specific application's complete infrastructure map. Example: "HR Self-Service Application" is an Application Service that uses the Oracle Database Platform Technical Service.

Section 6

Domain 4 — Infrastructure Layer (CMDB CIs)

Domain 4 is what you've been studying throughout Parts 2 and 3 — the actual CI records populated by Discovery, SGC, Import Sets, and other ingestion tools.

In the CSDM context, these CIs are connected upward:

A physical server CI belongs to a Technical Service (e.g., "Linux Platform")
A database instance CI belongs to an Application Service (e.g., "HR Application Service")
An application server CI is mapped by Service Mapping into an Application Service

CSDM does not change how CIs are discovered or stored — it adds a structured relationship layer on top of the raw CI data.

⚠

Exam Pattern — CSDM Requires CMDB Data to Work CSDM is a model, not a tool. It only provides value if the CMDB has accurate, complete CI data in Domain 4 and those CIs are properly linked up through Domains 3, 2, and 1. Without good CMDB data, CSDM relationships are empty or incorrect. This is why CMDB data quality (Part 6) and ingestion quality (Parts 2-4) are prerequisites for effective CSDM implementation.

Section 7

CSDM Versions — Understanding Framework Evolution

ServiceNow periodically updates the CSDM framework. Different versions introduce new CI classes, deprecate old ones, and refine the relationship model. Understanding CSDM versions matters for the exam because:

Organizations may be on different CSDM versions
Older ServiceNow instances may have deprecated class names
The exam may reference CSDM v3.x concepts

Key CSDM Version Changes

Version	Key Change
CSDM 1.x	Initial framework. Introduced Business Application, Application Service. Basic four-domain model.
CSDM 2.x	Added Service Offering, Service Commitment. Refined Technical Service definition.
CSDM 3.x	Added Business Capability. Introduced Product. Strengthened CMDB Health scoring for CSDM completeness.
CSDM 4.x	Further refinement. Added dynamic CI groups for CSDM modeling. Focus on automated relationship population.
CSDM 5 (Zurich+)	Renamed "Application Service" → "Service Instance" (`cmdb_ci_service_auto` remains the table name). Introduced Foundation domain. Current version. High-probability exam trap: exam scenarios may use either term — know both.

💡

Tip — CSDM is a Framework, Not a Plugin CSDM is not a plugin you activate — it's a set of best-practice CI class usages and relationship patterns. The CI classes it uses already exist in ServiceNow's CMDB. CSDM adoption is about using those classes correctly and building the relationships between them, not about installing new software.

Section 8

CSDM Adoption Journey — From Zero to Full

ServiceNow recognizes that full CSDM implementation is a journey, not a one-day project. They define a maturity model with levels:

Level 0 — Starting Point

No CSDM

Raw CI records exist in the CMDB but have no service relationships. Infrastructure is discoverable but unconnected to any business context. Change impact and incident routing rely entirely on manual knowledge.

Level 1 — Foundation

Basic CMDB Health

CIs are populated and reasonably accurate. Identification Rules are configured. Discovery runs regularly. IRE deduplication is active. There is still no service model — CIs are islands, not connected to services or business applications.

Level 2 — Service Model

Application Services Defined

Service Mapping has been run. Application Services (cmdb_ci_service_auto) exist and CIs are linked as members. The technical infrastructure is now connected to logical services. Change impact analysis becomes possible.

Level 3 — Business Context

Business Applications Linked

Business Applications (cmdb_ci_business_app) are created and linked to Application Services. Business owners are assigned. ServiceNow can now route incidents and changes to the correct business stakeholder automatically.

Level 4 — Full CSDM

Complete Business Hierarchy

Business Capabilities, Products, Service Offerings, and Commitments are all populated and linked through the full CSDM chain. The platform can measure business outcomes, enforce SLAs per capability, and provide complete impact analysis from infrastructure CI to business stakeholder.

The CIS-DF exam primarily tests Level 2-3 concepts: understanding what Application Services are, how they relate to Business Applications, and how Service Mapping populates the service model.

Exam Quick Reference

CSDM Framework — Key Facts

CSDM = Common Service Data Model. ServiceNow's framework for mapping infrastructure CIs to business services and capabilities.
Four domains: (1) Business — capabilities, applications; (2) Design — services, offerings; (3) Manage — technical services, vendors, contracts; (4) Infrastructure CIs.
Business Application (cmdb_ci_business_app) = business-level name for an application. NOT a server or app instance CI.
Application Service (cmdb_ci_service_auto) = the technical service map containing all CIs. Populated by Service Mapping. Sits between Business (Domain 2) and Infrastructure (Domain 4). Renamed "Service Instance" in CSDM 5 (Zurich+).
Technical Service = internal shared IT service used by Application Services (e.g., "Database Platform").
CSDM is a framework, not a plugin. Uses existing CMDB CI classes, just in a prescribed way.
CSDM requires good CMDB data. No value without accurate Domain 4 CIs.
Service Mapping populates Application Services. Without Service Mapping, the Domain 2 to Domain 4 link is incomplete.
Business impact analysis requires CSDM relationships to be populated — CI → Technical Service → Application Service → Business Application → Business Capability chain.

Term Grid

CSDM (Common Service Data Model)

ServiceNow's prescribed framework for organizing CI data into four domains: Business, Design, Manage, and Infrastructure. Enables business impact analysis and service-aware ITSM.

Business Application (cmdb_ci_business_app)

Domain 1 CSDM object. The business-level name for an application as recognized by stakeholders. Connected downward to Application Services (Domain 2). Not a technical CI.

Application Service (cmdb_ci_service_auto)

Domain 2 CSDM object. The technical service map — contains all infrastructure CIs that make the application run. Populated by Service Mapping. Critical junction between business and IT.

Technical Service

Domain 3 CSDM object. A shared internal IT service used by Application Services. Example: "Oracle Database Platform" used by multiple applications. Not visible to business users.

Business Capability

Domain 1 CSDM object. A core business function (what the business can do). Higher level than Business Application. Example: "Fraud Detection" is a capability enabled by multiple applications.

Service Offering

Domain 2 CSDM object. What IT formally offers to consumers — tied to a Service Commitment (SLA). Represents the "product catalog" view of IT services.

Exam Checkpoint

Practice Questions

Click any question to reveal the answer and explanation.

1. A company's CTO asks "When this database server fails, which business applications are impacted?" The CMDB has all server CIs accurately populated. However, the company has not implemented CSDM relationships. What answer can ServiceNow provide automatically?

A) A complete list of all affected Business Applications with their business owners

B) No answer — the system cannot automatically determine business application impact without CSDM relationships linking CIs to Business Applications

C) A partial answer showing only CIs related to the database server

D) An answer based on the database server's support_group field

💡 What does CSDM provide that raw CMDB data alone cannot?

Answer: B — Without CSDM relationships (CI → Application Service → Business Application), ServiceNow has no machine-readable way to trace from a database server CI to the Business Applications it supports. The CMDB might show that the server is "related" to other CIs, but the business-level impact can't be determined automatically. This is the exact value proposition of CSDM — connecting infrastructure events to business outcomes. Raw CI data alone can only answer "what else is connected to this CI," not "what business applications does this support."

2. In CSDM, what is the correct CI class for a "Business Application" — the named application that business stakeholders identify (e.g., "Salesforce CRM")?

A) cmdb_ci_appl (software instance)

B) cmdb_ci_server (the server running the application)

C) cmdb_ci_business_app

D) cmdb_ci_service_auto (Application Service)

💡 CSDM uses specific CI classes for each domain concept. Which class represents the business-level application concept?

Answer: C — cmdb_ci_business_app is the CSDM-prescribed CI class for Business Applications (Domain 1). This is distinct from cmdb_ci_appl (software installation CI in Domain 4), cmdb_ci_server (infrastructure), and cmdb_ci_service_auto (Application Service in Domain 2). The Business Application is the business-level name; the Application Service is the technical implementation. These are two separate records linked by a relationship.

3. A ServiceNow administrator has accurate server and database CIs from Discovery. Service Mapping has been run and Application Services are defined. Business Applications have been created and linked to Application Services. Which CSDM adoption level does this represent?

A) Level 1 — Basic CMDB Health only

B) Level 2 — Application Services Defined

C) Level 3 — Business Applications Linked

D) Level 4 — Full Business Hierarchy

💡 What's the distinguishing factor between Level 2 and Level 3?

Answer: C — Level 2 means Application Services are defined and linked to infrastructure CIs (via Service Mapping). Level 3 adds Business Applications created and linked to Application Services. This scenario has both: Application Services from Service Mapping AND Business Applications linked to those services. Level 4 would additionally require Business Capabilities, Products, Service Offerings, and Service Commitments to be fully populated — which isn't described here.

4. What is the difference between an "Application Service" (cmdb_ci_service_auto, Domain 2) and a "Technical Service" (Domain 3) in CSDM?

A) Application Service is for cloud CIs only; Technical Service is for on-premises CIs

B) Application Service maps a complete application's infrastructure (visible to business users); Technical Service is a shared internal IT capability used by multiple Application Services

C) They are the same thing — "Application Service" and "Technical Service" are interchangeable CSDM terms

D) Technical Service is automatically populated by Discovery; Application Service requires manual creation

💡 Think about who uses each type of service — end-users/business vs. IT operations internally.

Answer: B — Application Services (Domain 2) are the complete technical implementation of a named application that business users and service managers deal with (e.g., "HR Self-Service Application" containing its servers, databases, and load balancers). Technical Services (Domain 3) are shared internal IT components that multiple Application Services depend on (e.g., "Oracle Database Platform" used by HR, Finance, and CRM applications). The Technical Service is transparent to end users but critical for IT operations management.

5. A company wants to implement CSDM to enable automated business impact analysis. Their CMDB is empty — no CIs have been discovered yet. What must happen first before CSDM relationships can provide meaningful business impact data?

A) Business Applications and Business Capabilities must be created first

B) The CSDM plugin must be installed and licensed

C) Domain 4 infrastructure CIs must first be populated (via Discovery, SGC, or Import Sets) and then linked into Application Services and Business Applications

D) Service Offering and Service Commitment records must be configured first

💡 CSDM is a layered model — which layer is the foundation that all others depend on?

Answer: C — CSDM relationships only provide value when they're connected to real CI data. Without Domain 4 CIs (servers, databases, network devices populated by Discovery or other ingestion tools), the higher CSDM layers have nothing to link to. The correct implementation order: (1) populate CI data via Discovery/SGC/Import Sets, (2) run Service Mapping to create Application Services, (3) create Business Applications and link to Application Services, (4) add Business Capabilities and other Domain 1 concepts. CSDM is not a plugin (B) — it uses existing CI classes.

Exam Checkpoint

Practice Questions

4 questions · Select an answer to see the explanation immediately.

CSDM Framework Quiz 1 / 4

A CTO asks which business applications are impacted when the database server DB-PROD-01 fails. The CMDB has accurate CI data but no CSDM relationships. What can ServiceNow automatically determine?

💡 Explanation

B is correct. Without CSDM relationships (CI → Application Service → Business Application), ServiceNow has no machine-readable path from a database server CI to the Business Applications it supports. Accurate CI data alone only tells you what the server is — not what business functions it enables. CSDM relationships are the bridge between infrastructure events and business outcomes. This is the core value proposition of CSDM implementation.

← CI Class Manager CSDM Service Modeling →