ServiceNow
CSDM Explained for Beginners: How Enterprises Connect Business Services to Technology
What is CSDM?
CSDM (Common Service Data Model) is ServiceNow's standard way to model services, applications, technical components, and ownership relationships in CMDB.
In simple terms: CSDM gives one common language so business, operations, and engineering talk about the same service objects.
Why CSDM Matters
- Incidents can be tied to actual business services.
- Change risk can be evaluated using service impact context.
- Executives can see technical outages in business terms.
Enterprise Example: Retail Checkout Outage
Without CSDM, outage records pointed to random servers. Leadership could not assess business impact quickly.
After CSDM alignment, incidents were linked to the Checkout Business Service, enabling instant visibility into affected stores and revenue risk.
CSDM Tables in the Platform
Each CSDM layer maps to a real table you can query:
cmdb_ci_service— Business Services (what the business cares about)cmdb_ci_service_auto— Application Services / Service Instances (the deployed app stack that delivers a capability)cmdb_ci_business_app— Business Applications (owned, governed app records)cmdb_ci_appl— Technical Application instances
// Quick CSDM health check: find business apps without owners
var gr = new GlideRecord('cmdb_ci_business_app');
gr.addNullQuery('owned_by'); // Official null API (not addQuery(..., 'NULL'))
gr.addQuery('install_status', '1'); // Installed
gr.query();
var count = 0;
while (gr.next()) { count++; }
gs.info('Unowned business apps: ' + count);
CSDM in Very Simple Layers
| Layer | What it Represents | Example |
|---|---|---|
| Business Service | What the business sells/uses | Digital Payments |
| Application Service | App behavior users consume | Checkout API |
| Application/CI | Technical implementation | Payment microservice, DB, queue |
Most Common Beginner Mistakes
- Treating every server as a business service.
- Missing ownership fields (service owner, support group).
- No relationship governance between app services and CIs.
Start Small
Model 3-5 critical services first (order-to-cash, payroll, identity, customer support) before scaling across the enterprise.
What "Good" Looks Like
- Incident and change records consistently reference services.
- Ownership is explicit and complete.
- Service impact paths are visible in outages and major incidents.
When you are ready for the full picture — every layer, the relationship types, and the GlideRecord queries that trace an outage from a Linux box to a business service — read the deep-dive post "CSDM End to End: How a Single Outage Traces from a Linux Box to a Business Service" on this blog.