How CSDM Organizes Your ServiceNow Data

[HasiniC]

What is CSDM (Common Service Data Model)?

The Common Service Data Model (CSDM) is ServiceNow’s official blueprint for organizing data inside the CMDB (Configuration Management Database).

It tells you:

• Which tables to use
• How they connect (relationships)
• How to model “services” correctly

Basically, CSDM is like a map showing how all your IT services, applications, and infrastructure fit together — so ServiceNow modules (ITSM, ITOM, ITBM/SPM, etc.) can work together properly.

2. Why CSDM Exists (Background Story)

Before CSDM:

Different ServiceNow teams and customers were creating their own data models:

• ITSM (incident management) had one structure.
• ITOM (operations) had another.
• ITBM (business management) had yet another.

Because of this, data didn’t match up, and you couldn’t easily report on or manage services across modules.

Then in 2017:

ServiceNow realized they needed one unified model — one common definition of what a Service is and how it connects to other data (like applications, infrastructure, and users).

So in 2018, they launched CSDM 1.0, and it’s been evolving since then.
Now, we have CSDM 5.0, which is more complete, prescriptive, and ready for future products.

Real-Life Example: A Bank Using ServiceNow Without CSDM

Imagine a large bank called BrightBank.
They use ServiceNow for different purposes across departments:

1. The ITSM Team (IT Service Management)

• Handles incidents, problems, and changes.
• They create a record called “Loan Processing Service” in their own CMDB structure to track user issues.
• They store it in a table they created called u_it_services.

In their mind, “Loan Processing Service” = an application users depend on.

2. The ITOM Team (IT Operations Management)

• Manages servers, networks, and databases.
• They also have an entry called “Loan Processing Application”, but they store it in a completely different custom table called u_business_applications.
• They link it to discovery data (servers, databases, etc.).

For them, “Loan Processing Application” = a technical app running on servers.

3. The ITBM (Business Management / SPM) Team

• Tracks projects, portfolios, and costs.
• They have another entry named “Loan Workflow Portal”, which they consider part of their “Strategic Business Capability.”
• They store it in u_portfolio_services.

For them, this service = a business capability enabling customer loans.

The Problem Without CSDM:

Even though all three names —

“Loan Processing Service,” “Loan Processing Application,” and “Loan Workflow Portal” —

refer to the same real-world service,
they exist in different tables, with different names, and no relationships.

So when:

• A server goes down (ITOM) → ITSM can’t automatically link it to affected users.
• A new project launches (ITBM) → ITSM doesn’t see the connection to existing services.
• Reporting on “Loan Processing Service uptime” → impossible, since data is fragmented.

The result: silos, duplicated records, messy reports, and zero unified view.

Now the Same Bank With CSDM

CSDM gives clear, standard tables and relationships to use:

• Business Service: “Loan Processing Service”
• Application Service: “Loan Processing Application”
• Application: “Loan Workflow Portal App”
• Infrastructure CIs: Servers, databases, APIs

Each one links properly through the CMDB:

Business Service → Application Service → Application → Infrastructure

So now:

• ITSM incidents automatically show which business service is impacted.
• ITOM can trace infrastructure issues back to business impact.
• ITBM (SPM) can track cost, projects, and performance for the same service.
• Reports are unified — everyone’s “speaking the same data language.”

3. What CSDM Actually Does

CSDM is not a product or something you install.
It’s a framework (a set of rules and relationships) that guides how your CMDB should be structured.

Main Goals:

• Standardize how “services” are defined and stored.
• Help all ServiceNow apps (ITSM, ITOM, SPM, SecOps, etc.) use the same data.
• Enable end-to-end service management (from infrastructure to business outcomes).
• Simplify reporting and integrations.

4. Technical Terms Explained Simply

Term	Simple Meaning	Example
CMDB (Configuration Management Database)	The central database in ServiceNow that stores information about everything in your IT environment.	Servers, laptops, software, applications, users, etc.
Configuration Item (CI)	Any item stored in CMDB (hardware, software, service, etc.).	A database server, a business application, a router.
Service	Something your IT department provides to users or the business.	“Email Service,” “Payroll System,” “Employee Portal.”
Out-of-Box (OOB)	Features or tables that come with ServiceNow without customization.	The “cmdb_ci” table is OOB.
Prescriptive Guidance	Best practices recommended by ServiceNow on how to configure your CMDB.	“Use the ‘Business Service’ table for user-facing services.”
Relationship	A connection between two CIs.	“Email Service runs on Exchange Server.”
Service Level Management (SLM)	Tracking performance or uptime of services as per agreements (SLAs).	Ensuring “Email Service” is 99.9% available.
CSDM-Compliant	Configured following CSDM standards.	If you use the correct tables, fields, and relationships as per CSDM, your CMDB is CSDM-compliant.

5. How the Data Model Works (With Example)

Imagine your company provides an Employee Portal — a web-based system where employees apply for leave, download payslips, etc.

Without CSDM:

Different teams record it differently:

• ITSM calls it an “Application.”
• ITOM calls it a “Service.”
• ITBM calls it a “Project.”
  No consistent relationship = confusing reports.

With CSDM:

You structure it properly:

CSDM Layer	Example Record	Description
Business Services	Employee Self-Service Portal	What the business uses (visible to end users)
Technical Services / Application Services	HR Portal Service	The underlying IT service supporting it
Application	HR Web App	The actual software application
Infrastructure CIs	Web Server, Database Server	The technical components that host/run it

These layers are connected via relationships, so you can trace from business impact down to the infrastructure.

6. Key CSDM Principles (from the White Paper)

Principle	Meaning
CSDM is free	You don’t need to buy anything — it’s built into ServiceNow.
You may need plugins	Some tables/features are added when you activate related plugins (e.g., Service Portfolio).
CSDM ≠ product	It’s not a separate module, app, or SKU.
CSDM ≠ process	It’s not an implementation guide or code you install.
CSDM provides structure	It tells you where and how to store data correctly.

7. Why It’s Important

For ServiceNow Customers:

• Ensures all modules “speak the same language.”
• Makes reports and dashboards consistent.
• Reduces rework, duplication, and confusion.
• Enables Service Mapping, Service Portfolio, Impact Analysis, and AI/ML predictions accurately.

For Implementers / Admins:

• Acts as a blueprint when building your CMDB.
• Ensures new integrations or customizations are compatible.
• Prepares your CMDB for advanced modules (like AIOps or Service Portfolio Management).

8. Example of How CSDM Helps in Real Life

Let’s say an email outage occurs.

• Without CSDM: The Incident record can’t easily show which server caused the problem or which business services are impacted.
• With CSDM: The Incident links to the “Email Service” (a Business Service), which is tied to the “Exchange Application,” which runs on a “Windows Server.”
  So IT can quickly identify the root cause, affected users, and impacted business functions.

That’s the power of a properly modeled CSDM-compliant CMDB.