What Is the Common Service Data Model (CSDM)?
The Common Service Data Model (CSDM) is a standard framework from ServiceNow that defines how to map and structure service-related data inside a Configuration Management Database (CMDB). It defines where different types of data should be stored and how records such as applications, services, infrastructure, and business capabilities relate to each other. CMDB vs. CSDM: The CMDB stores the physical data (like servers and applications), while the CSDM provides the rules and guidelines for how to connect and organize that data. The five domains of CSDM:- Foundation: Core reference data like users, groups, and locations.
- Design & Planning: Business capabilities and applications.
- Build: Logical development details and deployed application services.
- Manage Technical Services: Technical services and offerings that support applications and other services.
- Sell and Consume: Consumer-facing services, offerings, subscriptions, and related service information.
What Is the Purpose of CSDM?
Standardize Service and Configuration Data
CSDM defines a standard structure for storing service and configuration data in the ServiceNow CMDB. It specifies which classes should represent business applications, application services, technical services, service offerings, and other service-related records. This reduces the need for teams to create their own data models. Standardization also makes the same CMDB data usable across multiple ServiceNow processes. Incident, change, problem, asset, and service management processes can reference consistent records and relationships. This reduces conflicting data structures and makes integrations and reporting easier to maintain.Create a Common Vocabulary Across IT and the Business
CSDM provides shared definitions for concepts such as business applications, application services, technical services, and service offerings. Teams can use these definitions instead of assigning different meanings to the same terms. This is especially useful when IT operations, application teams, service owners, and business stakeholders work with the same services. A common vocabulary also clarifies how business and technical concepts connect. For example, a business application can be associated with the application services that represent its deployed instances. These relationships help teams discuss ownership, dependencies, costs, risks, and service performance using the same model.Improve CMDB Data Consistency
CSDM provides guidance on where records belong in the CMDB and how different classes should relate to each other. Following these rules reduces duplicate records, incorrect classifications, and inconsistent relationships. It also makes it easier to establish governance rules for creating and maintaining CMDB data. Consistent data improves processes that depend on accurate CMDB relationships. Teams can perform more reliable impact analysis during incidents and changes, trace dependencies between services and infrastructure, and generate reports using standardized data. This makes the CMDB more useful as a shared source of service information.CSDM vs. CMDB: What Is the Difference?
A configuration management database (CMDB) is the system that stores information about configuration items (CIs) and their relationships. CIs can include servers, databases, network devices, applications, and services. ServiceNow processes can use this information to determine what infrastructure exists, how components depend on each other, and which services could be affected by an incident or change. CSDM is a framework for organizing service-related data within the ServiceNow CMDB. It defines recommended classes, terminology, and relationships for modeling areas such as business applications, application services, technical services, and service offerings. CSDM therefore does not replace the CMDB. It provides rules and guidance that help organizations use the CMDB consistently.| Area | CSDM | CMDB |
| Purpose | Defines how service-related data should be modeled | Stores configuration and service data |
| Type | Data model and framework | Database |
| Main focus | Classes, relationships, terminology, and modeling practices | CIs, attributes, and relationships |
| Examples | Business applications, application services, service offerings | Servers, databases, applications, network devices, services |
| Role | Provides structure and modeling guidance | Provides the underlying data repository |
| Relationship | Defines how relevant CMDB data should be organized | Implements and stores data structured according to the model |
How Does CSDM Work?
Step 1: Define Standard Service and CI Classes
CSDM uses standard ServiceNow CMDB classes to represent different types of records. For example, organizations can model business applications, application services, technical services, service offerings, servers, and databases using classes intended for those purposes. Using the correct class determines what a record represents and how it should interact with other records. This prevents teams from placing different concepts in the same class or creating unnecessary custom classes that make the CMDB harder to maintain.Step 2: Organize Data into CSDM Domains
CSDM groups data into domains that represent different parts of the service lifecycle and operating model. These domains help separate concepts such as business capabilities and applications from service delivery and the underlying technical infrastructure. Each domain has specified record types and relationships. Organizing data this way gives teams a structured method for determining where information belongs while still connecting records across domains when necessary.Step 3: Establish Relationships Between Configuration Items
Relationships describe how CIs depend on, provide, host, or otherwise interact with one another. For example, an application service can depend on a database, while that database may run on a particular server or cloud resource. These relationships turn individual CMDB records into a dependency model. ServiceNow can use that model to identify affected components during incidents and changes and help teams understand how failures can propagate through a service. Related content: Read our article about ServiceNow service mappingStep 4: Connect Business Applications, Services, and Infrastructure
CSDM connects high-level application and service records with the operational components that support them. A business application can be associated with deployed application services, which can then be connected to infrastructure such as servers, databases, and cloud resources. This creates traceability from a business-facing concept down to its technical dependencies. Teams can use these connections to understand which technology supports an application and which business services may be affected when an infrastructure component fails.Step 5: Apply Consistent Service Modeling
CSDM provides modeling guidance that teams can apply across applications, services, and organizational units. Instead of each team defining services differently, they can use common classes, relationship types, naming conventions, and ownership rules. Consistency makes CMDB data easier to govern and reuse. It also improves reporting and automation because ServiceNow processes can operate on predictable data structures rather than account for different models created by individual teams.What Are the CSDM Domains?
1. Foundation
The Foundation domain contains shared reference data used throughout CSDM. This includes information about organizations, locations, users, groups, and other common records that provide context for applications and services. Foundation data supports the other CSDM domains rather than representing a service lifecycle stage by itself. Accurate foundation records make it possible to assign ownership, identify responsible groups, associate services with locations, and maintain consistent organizational information.2. Design and Planning
The Design and Planning domain describes what the business does and the applications that support those activities. It includes concepts such as business capabilities, business applications, information objects, and related planning data. Organizations can use this domain to connect technology investments with business needs. For example, teams can identify which business capabilities depend on an application and use that information when evaluating application risk, cost, lifecycle status, or modernization plans.3. Build
The Build domain represents applications and services from a development and deployment perspective. It helps connect logical application concepts with the deployed application services that run in different environments. This domain creates a bridge between application planning and operational management. Teams can model deployed instances such as production or non-production application services and connect them to the infrastructure and other CIs required for operation.4. Manage Technical Services
The Manage Technical Services domain focuses on the technical services that IT teams provide and operate. These can include infrastructure, platform, network, database, hosting, and other technology services that support applications and higher-level services. Technical services can be divided into service offerings to represent different levels or variants of delivery. Modeling these services consistently helps teams manage ownership, support responsibilities, dependencies, availability, and operational performance.5. Sell and Consume
The Sell and Consume domain represents services and offerings from the consumer’s perspective. It describes what users or customers can consume rather than focusing on the technical components used to provide the service. This domain can model service offerings, consumers, subscriptions, and related service information. Connecting consumer-facing services to the rest of the CSDM model provides traceability between what is offered and the applications, technical services, and infrastructure involved in delivering it.Key CSDM Components and Data Objects
CSDM uses a set of standard data objects to represent business needs, applications, services, and supporting technology. These objects are stored in appropriate ServiceNow CMDB classes and connected through defined relationships. Key components include:- Business capabilities: Represent what an organization needs to be able to do, such as customer management or order fulfillment.
- Business applications: Represent logical applications used to support business capabilities and processes.
- Application services: Represent deployed instances of applications and connect applications to their operational dependencies.
- Business services: Represent services delivered to business users or customers.
- Technical services: Represent technology services that support applications and other services, such as hosting, networking, or database services.
- Service offerings: Represent the exact ways a business or technical service is provided to consumers, often with distinct availability, scope, or service commitments.
- Configuration items: Represent infrastructure and other managed components, such as servers, databases, network devices, and cloud resources.
- Relationships: Connect CSDM objects and CIs to show dependencies, service delivery paths, and how technical components support applications and services.
CSDM Implementation Best Practices
Organizations should consider the following best practices when working with ServiceNow’s CSDM framework.1. Establish Foundation Data Before Building Complex Service Models
Start with the reference data that other CSDM records depend on. This includes users, groups, companies, locations, departments, and ownership information. Define standards for these records and identify authoritative data sources before modeling applications and services. Reliable foundation data prevents errors from spreading into higher-level service models. For example, standardized support groups and ownership records make it easier to assign responsibility for business applications, application services, and technical services. Key actions:- Define authoritative sources for foundation data.
- Standardize ownership and support records.
- Assign owners responsible for maintaining reference data.
2. Use Out-of-the-Box CSDM Tables Where Possible
Use standard ServiceNow tables and classes when they meet the requirements of the data being modeled. CSDM is designed around these structures, so using them helps preserve compatibility with ServiceNow applications, reporting, upgrades, and platform features. Create custom classes only when a requirement cannot be represented correctly with the standard model. Before adding one, determine what the object represents, why an existing class is insufficient, and how the custom class will relate to standard CSDM objects. Key actions:- Map data to standard CSDM classes first.
- Avoid unnecessary custom tables and classes.
- Document requirements before extending the standard model.
3. Maintain Accurate CI Relationships
A service model is only useful when the relationships between its CIs reflect the actual environment. Define how applications, application services, technical services, servers, databases, cloud resources, and other components should connect. Use automated discovery and service mapping where appropriate, but do not assume discovered relationships are always complete or correct. Establish processes for reviewing important dependencies, removing obsolete relationships, and resolving conflicting data from multiple sources. Key actions:- Validate critical dependencies against the actual environment.
- Remove stale, duplicate, or incorrect relationships.
- Review automatically discovered relationships regularly.
4. Establish CMDB Data Quality Metrics
Define measurable criteria for evaluating the health of CSDM and CMDB data. Useful metrics include required-field completeness, duplicate records, stale CIs, invalid relationships, orphaned records, and compliance with defined identification and reconciliation rules. Track these metrics by CI class, service, or data owner so teams can identify where problems originate. Assign thresholds and ownership for remediation rather than relying on a single overall CMDB health score that can hide problems in critical service data. Key actions:- Track completeness, duplicates, stale CIs, and invalid relationships.
- Set acceptable thresholds for important CI classes.
- Assign owners responsible for correcting data quality issues.
5. Continuously Validate CSDM Compliance
CSDM implementation should be treated as an ongoing governance process rather than a one-time modeling project. New applications, services, integrations, and platform changes can introduce records that do not follow established class and relationship standards. Review the model periodically against the CSDM guidance used by your ServiceNow release and organizational requirements. Combine automated checks with targeted reviews of important services to find incorrect classifications, missing relationships, unsupported customizations, and other deviations before they affect downstream processes. Key actions:- Review data against current CSDM guidance regularly.
- Detect incorrect classifications and missing relationships.
- Correct unsupported customizations and modeling deviations.
Keeping Your CSDM Model Accurate with Faddom
A CSDM model is only as reliable as the CMDB data behind it, and configuration records tend to drift as environments change. Faddom connects to your existing IT ecosystem to enrich monitoring and service management tools with real-time application dependency context, creating a single source of truth for how applications and infrastructure actually communicate. It works agentlessly and passively, without configuration changes, agents, or traffic mirroring, so the relationships feeding your CSDM classes and service models reflect the live environment rather than manual assumptions. Key capabilities of Faddom:- ServiceNow CMDB enrichment: Enriches incidents, changes, and CMDB records with real-time application dependency context, supporting more reliable impact analysis.
- Agentless, passive collection: Collects and analyzes traffic using widely adopted protocols such as sFlow, NetFlow, IPFIX, SNMP, SSH, WMI, and syslog, with no agents, no active scanning, and no performance impact.
- Unified view across data sources: Correlates data from network traffic, infrastructure, and cloud-native sources to automatically build and maintain accurate application dependency maps across on-premises, cloud, and hybrid environments, including AWS and Azure flow logs.
- Continuous accuracy in dynamic environments: Continuously adapts to infrastructure and application changes, keeping dependency maps accurate even in highly dynamic or cloud-native environments.
- Fast, secure deployment: Deploys in under 60 minutes with read-only data collection, and works alongside your existing tools with no rip and replace.
- Extensible integrations: Offers native integrations with IT operations, monitoring, security, and identity tools, plus APIs, webhooks, and standard protocols to extend integrations as needed.