CSDM Fundamentals
While CSDM Fundamentals is only 11% of the exam, understanding CSDM is critical for answering questions across ALL other domains. CSDM provides the framework for how data should be organized, and exam questions frequently present scenarios requiring CSDM domain placement decisions.
What is CSDM?
What is CSDM?
The Common Service Data Model (CSDM) is ServiceNow's prescriptive data model standard. It identifies what data should be managed in CMDB and related tables, how it should be organized across domains, and how different products consume it.
All ServiceNow products are standardizing on CSDM — it is the foundational data architecture.
CSDM is NOT a product or plugin — it is a framework, a standard, a set of guidelines. The tables and classes exist in the platform regardless of CSDM, but CSDM provides the blueprint for how to populate and relate them correctly.
- CSDM 4.0 defined five domains
- CSDM 5.0 expanded to seven domains
- The exam primarily references the five-domain model
CSDM Domain 1 — Foundation (Grey)
Domain 1 — Foundation (Grey)
Contains base referential data used by all other domains. Foundation data is mostly stored OUTSIDE the CMDB (non-CMDB tables). Must be established BEFORE populating other domains.
Foundation Domain Tables
| Table | Description | Example |
|---|---|---|
| sys_user | People records | John Smith |
| cmn_location | Physical locations | NYC Data Center |
| core_company | Organizations/vendors | Acme Corp, AWS |
| cmn_department | Organizational departments | IT Operations |
| business_process | Business processes (NOTE: this IS a CMDB table) | Order Fulfillment |
Key personas: Data Steward, Process Owner, Product Owner, Contract Manager.
Most Foundation data lives in non-CMDB tables (sys_user, cmn_location, core_company, cmn_department). The notable exception is business_process, which IS a CMDB table.
CSDM Domain 2 — Design (Orange)
Domain 2 — Design (Orange)
Strategic layer representing what the business wants and needs. Contains the inventory of business applications and strategic capabilities.
Design Domain Tables
| Table | Description |
|---|---|
| cmdb_ci_business_app | Business Application — inventory/catalog record of an application; NEVER operational |
| cmdb_ci_business_capability | Strategic capabilities the business must perform; strategic planning entity, not operational |
Key persona: Enterprise Architect.
Business Application (cmdb_ci_business_app) is NEVER an operational CI. You cannot and should not open an Incident, Change, or Problem against a Business Application. It exists only as an inventory/catalog record in the Design domain. The operational CI is the Application Service (cmdb_ci_service_auto) in the Manage Technical Services domain. The CSDM whitepaper explicitly states: "Business Application is NOT an operational CI and should not be used in incident, problem and change."
CSDM Domain 3 — Build (Red)
Domain 3 — Build (Red)
The DevOps layer representing logical code and development artifacts. Connects to DevOps tools, represents what is being built before deployment.
Build Domain Tables
| Table | Description |
|---|---|
| cmdb_ci_sdlc_component | Software Development Lifecycle Component — represents a unique development effort of code |
| cmdb_ci_service | Base service class extended by specific service types |
Key persona: Application Developer.
Once code is deployed, the deployed instance becomes an Application Service in the Manage Technical Services domain.
CSDM Domain 4 — Manage Technical Services (Green)
Domain 4 — Manage Technical Services (Green)
The operations layer — the "engine room." Contains all deployed infrastructure, application instances, technical services, and dynamic groupings.
Manage Technical Services Domain Tables
| Table | CI Type | Operational? | Example |
|---|---|---|---|
| cmdb_ci_service_auto | Application Service | YES — incidents are recorded here | Salesforce – Production |
| cmdb_ci_service_technical | Technical Service | YES | Hosting – Windows, Network Access |
| service_offering | Technical Service Offering | YES | Hosting – Windows – Gold Tier |
| cmdb_ci_query_based_service | Dynamic CI Group | YES | All Linux Servers in NY |
| cmdb_ci_server, cmdb_ci_appl, etc. | Physical and virtual infrastructure CIs | YES | Various servers and applications |
Key personas: Technical Service Owner, Operations Manager.
A Dynamic CI Group (cmdb_ci_query_based_service) is a query-based wrapper that dynamically groups CIs based on filter criteria. Group membership is automatically maintained by the query. Sits in the Manage Technical Services domain.
CSDM Domain 5 — Sell / Consume (Blue)
Domain 5 — Sell / Consume (Blue)
The service portfolio layer — what the business consumes and what is offered to customers.
Sell / Consume Domain Tables
| Table | Description | Example |
|---|---|---|
| cmdb_ci_service_business | Business Service — customer-facing service consumed by the business | Email Service, CRM Service |
| service_offering | Business Service Offering — specific tier/variant | Email Service – Premium |
Key personas: Portfolio Manager, Service Owner.
CSDM 5.0 Additions
CSDM 5.0 Additions
CSDM 5.0 expanded the model from five to seven domains and introduced several new capabilities.
- Two additional domains: Ideation and Strategy (business planning, strategic ideation, enterprise architecture decisions), Build and Integration (expands Build to include service delivery integration and solution architecture)
- New CI classes: AI-specific (AI Function, AI Application), Operational Technology (OT) classes
- System Component Model for versioned product tracking
- Expanded product modeling capabilities
CSDM Implementation Phases
CSDM Implementation Phases
- Foundation Phase: Establish all base referential data — locations, users, departments, companies, contracts, business processes. Must exist before populating other domains.
- Crawl Phase: Minimum viable CSDM. Create Business Application records (inventory). Create Application Service records (deployed instances). Link each Application Service to its Business Application parent. Establish basic infrastructure relationships. Assign ownership (managed_by_group, owned_by). Determine business criticality. Key rule: Focus on the 25 most critical services first.
- Walk Phase: Add technical services layer. Create Technical Service records. Create Technical Service Offerings with Support Groups and Change Groups. Create Dynamic CI Groups. Ensure every CI in Manage Technical Services has relationship to a Technical Service Offering. Key rule: As data grows exponentially, strongly consider automated discovery.
- Run Phase: Full service portfolio. Create Business Service Offerings for customer-facing services. Build complete end-to-end service chains from Business Service to infrastructure. Introduce Information Objects for data governance.
- Fly Phase: Strategic alignment and full maturity. Add Business Capabilities for portfolio rationalization and investment planning. Connect services to business strategy and enterprise architecture. CMDB extends beyond operational concerns to drive digital transformation.
Remember the order: Foundation, Crawl, Walk, Run, Fly. The Crawl phase focuses on the 25 most critical services first. The Walk phase is where automated discovery becomes strongly recommended.
Technical Service vs Application Service
Technical Service vs Application Service
This distinction appears frequently on the exam.
Technical Service vs Application Service Comparison
| Attribute | Technical Service | Application Service |
|---|---|---|
| Table | cmdb_ci_service_technical | cmdb_ci_service_auto |
| What it represents | Infrastructure service | Deployed instance of a business application |
| Examples | Hosting, Network Access, Identity Management | Salesforce – Production |
| Operated by | Infrastructure teams | Application teams / end users interact with it |
| Role | Infrastructure capabilities that support application services | What users interact with directly |
Application Services represent what users interact with; Technical Services represent infrastructure capabilities that support them.
Lifecycle Mapping
Lifecycle Mapping
CSDM 4.0+ replaced legacy install_status and operational_status with lifecycle_stage and lifecycle_stage_status.
Lifecycle Fields
| Field | Purpose | Example Values |
|---|---|---|
| lifecycle_stage | High-level phase | Operational, End of Life, Retired |
| lifecycle_stage_status | Detailed status within stage | In Use, In Maintenance, Obsolete |
Configured through the CSDM Lifecycle Mapping tool which keeps them synchronized with legacy fields.
A stakeholder asks you to create a CI for Salesforce so they can track incidents against it. Which CSDM entities should you create and where?
Create TWO entities: (1) A Business Application record ('Salesforce') in the Design domain as the inventory record. (2) An Application Service record ('Salesforce – Production') in the Manage Technical Services domain as the operational CI. Incidents should be opened against the Application Service, NEVER against the Business Application. Link the Application Service to the Business Application and to its infrastructure CIs.
An application developer asks which CSDM domain their code artifacts should be tracked in.
The Build domain. SDLC Components (cmdb_ci_sdlc_component) represent development artifacts and code under development. Once the code is deployed, the deployed instance becomes an Application Service in the Manage Technical Services domain.
In CSDM 4.0+, which two fields replace the legacy install_status and operational_status for lifecycle management?
lifecycle_stage (high-level phase: Operational, End of Life, Retired) and lifecycle_stage_status (detailed status within the stage: In Use, In Maintenance, Obsolete). These are configured through the CSDM Lifecycle Mapping tool which keeps them synchronized with legacy fields.
What is the difference between a Technical Service and an Application Service in CSDM?
A Technical Service (cmdb_ci_service_technical) is an infrastructure service like hosting, network access, or identity management operated by infrastructure teams. An Application Service (cmdb_ci_service_auto) is a specific deployed instance of a business application, like 'Salesforce – Production.' Application Services represent what users interact with; Technical Services represent the infrastructure capabilities that support them.
Key Takeaways
- CSDM is a framework/standard, NOT a product or plugin — it provides the blueprint for organizing CMDB data
- Business Application (Design domain) is NEVER operational — NEVER open incidents against it
- Application Service (Manage Technical Services domain) is the operational CI where incidents go
- This Business App vs Application Service distinction is the MOST TESTED concept on the exam
- Five CSDM domains: Foundation (Grey), Design (Orange), Build (Red), Manage Technical Services (Green), Sell/Consume (Blue)
- Foundation data is mostly stored OUTSIDE the CMDB (non-CMDB tables like sys_user, cmn_location)
- Implementation phases: Foundation → Crawl → Walk → Run → Fly (start with 25 most critical services)
- Dynamic CI Groups (cmdb_ci_query_based_service) sit in Manage Technical Services — query-based, auto-maintained
- CSDM 5.0 expanded to 7 domains and added AI-specific and OT CI classes
- CSDM Lifecycle Mapping tool syncs legacy status fields with new lifecycle_stage/lifecycle_stage_status fields
- Technical Services = infrastructure capabilities operated by infra teams; Application Services = deployed app instances used by end users
Community-created study aids. Not official ServiceNow exam content.