Picture a busy airport. Hundreds of people doing their jobs - check-in staff, ground crew, pilots, security, duty-free and not one of them sharing a common operations manual. Flights get delayed. Bags go missing. Nobody quite knows who is responsible for what.
That is not too far from what happens inside a ServiceNow environment when nobody has agreed on how services should be named, connected, or owned. IT raises tickets against the wrong team. A server goes down and nobody can tell which business services are hit. Reports contradict each other. Sounds familiar?
CSDM - the Common Service Data Model is the fix. Not a product you purchase, not a module you switch on. It is a frameworkf of set of agreed definitions for how your IT services, applications, and infrastructure relate to each other inside ServiceNow.
A Quick History - From 2018 to CSDM 5.0
It started with an internal problem. Back in 2017, ServiceNow's own ITSM, ITOM and ITBM teams each had their own way of describing services and they did not line up. Customers were left trying to stitch it together themselves. CSDM 1.0 landed in 2018 as the first attempt at a shared answer, and it has been growing ever since.
|
Version |
Year |
What Actually Changed |
|
CSDM 1.0 |
2018 |
Three domains introduced - Business, Service, Application. |
|
CSDM 2.0 |
2019 |
Design and Sell/Consume domains added. The famous 'Crawl, Walk, Run, Fly' phases introduced. |
|
CSDM 3.0 |
2020 |
Foundation Data became its own domain. Product-specific views arrived for ITSM, ITOM, and others. |
|
CSDM 4.0 |
2022 |
Build domain joined the model. Lifecycle management and closer IT4IT alignment. |
|
CSDM 5.0 |
2025 |
Biggest update yet - 7 domains, AI tracking, SBOM, Value Streams and OT support. |
The CSDM Layers - How They Stack Up
CSDM is built in layers - each one describing a different level of your IT environment, from the boardroom all the way down to the server rack. Here is the visual hierarchy first, then the detail:
Figure 1: CSDM Layers
Now let us put real meaning to each layer - using a Laptop as the running example, since most people have requested one at some point:
|
CSDM Layer |
Definition |
Example (Laptop) |
|
Portfolio |
The umbrella - everything IT offers and manages |
IT Portfolio |
|
Business Capability |
What the business actually needs to function |
IT Asset Management |
|
Business Application |
The software that delivers that capability |
Microsoft Intune |
|
Application Service |
How the app stays available and accessible |
SCCM / Intune Device Mgmt Service |
|
Business Service |
What the employee actually experiences |
End-User Device Management |
|
Service Offering ★ |
The line item in your Service Catalog |
Laptop Provisioning / Repair / Replace |
|
Technical Service |
Servers, networks, infrastructure underneath |
Laptop CI, OS, Network, Active Directory |
★ Service Offerings are the direct bridge between CSDM and what employees see in the catalog. Every catalog item should map to a Service Offering.
How the Layers Talk to Each Other
CSDM is not just a labelling exercise - it is about relationships. Each layer has a defined dependency on the one below it and those dependencies are what make features like impact analysis actually work.
|
From This Layer |
Relationship |
To This Layer |
|
Business Capability |
Used by → |
Business Service, Business Application |
|
Business Service |
Depends on → |
Application Service, Technical Service |
|
Service Offering |
Belongs to → |
Business Service |
|
Business Application |
Provides → |
Application Service |
|
Application Service |
Depends on → |
Technical Service |
|
Technical Service |
Depends on → |
Infrastructure CIs - servers, databases, networks |
Here is why it matters in practice: if a server goes down at 2:00 hrs, ServiceNow can trace that failure upward through all the layers - automatically flagging which Business Services are degraded and which employees will feel the impact. That is called impact analysis. You only get it when CSDM is set up properly and have the relationships setup in CI Relationship table.
Three Real Examples - So You Can See It in Action
Abstract frameworks only make sense when you can see them applied. Here are three common enterprise scenarios mapped through CSDM:
SAP Finance
|
CSDM Layer |
Value |
|
Portfolio |
IT Portfolio |
|
Business Capability |
Financial Management |
|
Business Application |
SAP S/4HANA Finance |
|
Application Service |
SAP Financials Application Service (Production) |
|
Business Service |
Finance & Reporting |
|
Service Offering |
Accounts Payable / Accounts Receivable |
|
Technical Services |
SAP Basis Support, Database Hosting, App Server Infrastructure |
Server Provisioning
|
CSDM Layer |
Value |
|
Portfolio |
IT Portfolio |
|
Business Capability |
IT Infrastructure Management |
|
Business Application |
VMware vCenter |
|
Application Service |
Server Provisioning Service (Production) |
|
Business Service |
Server Hosting |
|
Service Offering |
Provision New Server / Decommission / Patch |
|
Technical Services |
Compute, Storage, Network, Virtualisation |
Adobe Creative Cloud
|
CSDM Layer |
Value |
|
Portfolio |
IT Portfolio |
|
Business Capability |
Marketing & Creative Design |
|
Business Application |
Adobe Creative Cloud |
|
Application Service |
Adobe License Management Service |
|
Business Service |
Creative Tools Access |
|
Service Offering |
Install / Uninstall Adobe |
|
Technical Services |
License & Cloud Access |
Does this have anything to do with Service Catalog?
A lot, actually and it is the connection most teams completely miss.
Your Service Catalog is the front door. The bit employees interact with. But the catalog only works well when everything behind it is properly organised - the right team, the right approval chain, the right cost centre, the right SLA, linked to the right underlying systems. That organisation is CSDM's job.
|
Without CSDM |
With CSDM Properly Set Up |
|
Incidents from catalog requests land on the wrong team |
Every request auto-routes based on the linked Service Offering and Business Service |
|
A server outage - nobody knows what services are affected |
Impact traced instantly from the failed CI up to affected employees |
|
SLA reporting is unreliable or manually maintained |
SLAs attach to proper Business Services with real, traceable data |
|
Software vulnerabilities are discovered after the fact |
SBOM in CSDM 5.0 flags exposure the moment a CVE is published |
|
AI tools are invisible, unmanaged assets in the environment |
AI agents sit in the CMDB as proper CIs with owners and lifecycle stages |
Let's Be Honest - You Don't Need CSDM to Survive
Here is something most CSDM articles will not tell you: Organisations run ServiceNow every single day without it and things get done. Requests are fulfilled. Incidents are resolved. Nobody is sitting in the dark.
So no, CSDM is not the difference between ServiceNow working and not working. It is the difference between ServiceNow working and ServiceNow working really well.
Remember that airport from the introduction? Flights still take off without a shared operations manual. Passengers still board. Bags mostly arrive. But everyone in the building is spending a little extra energy compensating by double-checking, chasing, improvising. The airport functions, but nobody would call it efficient. CSDM is the shared operations manual. It does not build the airport. It just makes everyone inside it stop guessing.
CSDM is not a magic wand. It takes effort to set up, it requires buy-in from multiple teams, and it is not something you complete in a weekend. But every organisation that has gone through the process says the same thing: they wish they had started earlier
