A CSDM service hierarchy should be structured as a four-layer model moving from technical infrastructure up to business-facing services: Technical Services at the base, then Application Services, then Business Services, and finally Business Capabilities at the top. Each layer represents a different level of abstraction, and records connect upward through defined relationships so that a configuration item can be traced all the way to the business outcome it supports.
This structure is defined by ServiceNow’s Common Service Data Model and is designed to give organizations a shared language between IT and the business. Getting the layering right from the start is the single most important factor in a successful CSDM implementation.
The sections below walk through each layer, how records connect across them, a concrete example, and the most common structural mistakes teams make.
What Are the Layers in a CSDM Service Hierarchy?
The CSDM service hierarchy has four primary layers: Technical Services, Application Services, Business Services, and Business Capabilities. Each layer serves a distinct purpose and audience. Technical Services describe infrastructure. Application Services describe software. Business Services describe what IT delivers to users. Business Capabilities describe what the business does with those services.
Breaking each layer down further:
- Technical Services sit at the foundation. These represent infrastructure components such as servers, networks, databases, and storage systems. They are owned and understood by operations and infrastructure teams.
- Application Services sit above technical services. An application service represents a deployed software application, such as an ERP system or a payroll application. It depends on one or more technical services to function.
- Business Services represent what IT delivers to the business or end users. Payroll processing, employee onboarding support, or financial reporting are examples. A business service is what a user actually experiences and what a service catalog entry typically maps to.
- Business Capabilities sit at the top. They represent the strategic functions the organization performs, such as financial management or workforce planning. Not every CSDM implementation requires this layer immediately, but it becomes critical when connecting IT investment to business outcomes.
The CSDM also defines additional constructs such as Service Offerings and Information Objects, but the four layers above form the structural backbone of any service hierarchy in ServiceNow.
How Do Records Connect Across the CSDM Structure?
Records in a CSDM service hierarchy connect through upward dependency relationships. A configuration item (CI) at the technical layer is related to an Application Service, which is related to a Business Service, which can be mapped to a Business Capability. These relationships are stored as records in ServiceNow’s CMDB and are what make end-to-end impact analysis possible.
The key relationship types used in the CSDM structure are:
- Hosted on / Runs on: A CI such as a virtual machine hosts an application service. This relationship is typically managed in the CMDB through CI relationship records.
- Depends on: An application service depends on one or more technical services. If the technical service fails, the dependency chain surfaces the upstream impact.
- Supports / Is supported by: A business service is supported by one or more application services. This is the bridge between the technical world and the user-facing world.
- Realizes: A business service realizes a business capability. This relationship is what connects IT delivery to strategic value.
These relationships are not just documentation. They drive ServiceNow features such as service impact analysis, incident routing, change risk calculation, and AI-based recommendations. If the relationships are incomplete or incorrect, those features produce misleading results. This is why relationship completeness is one of the most important data quality dimensions in any CSDM implementation.
What Does a CSDM Service Hierarchy Look Like in Practice?
A practical CSDM hierarchy for a payroll function might look like this: a physical server CI and a database CI at the technical layer support a Payroll Application Service, which in turn supports a Payroll Processing Business Service, which realizes a Workforce Management Business Capability. Each record in this chain is linked, auditable, and traceable.
Here is that example written out as a concrete model:
- Business Capability: Workforce Management
- Business Service: Payroll Processing
- Application Service: SAP Payroll Application
- Technical Services: SAP Application Server CI, Oracle Database CI, Storage Array CI
In ServiceNow, each of these records exists in a specific table. The Business Service record lives in the Business Service table. The Application Service record lives in the Application Service table. The CIs live in the CMDB. The relationships between them are stored as CI relationship records and service relationship records, depending on the layer.
This model gives the service desk a direct line of sight from a user-reported issue with payroll to the underlying infrastructure. It gives the change manager a way to assess the business risk of patching the Oracle database. And it gives leadership a way to see which business capabilities depend on which infrastructure investments.
What Mistakes Should You Avoid When Building a CSDM Service Hierarchy?
The most common mistakes in CSDM structure are collapsing layers together, leaving relationships unmapped, and building the hierarchy without enforcing data completeness rules. Each of these mistakes reduces the practical value of the model and makes the hierarchy unreliable for impact analysis, AI features, and service reporting.
Collapsing or skipping layers
A frequent shortcut is treating Application Services and Business Services as the same thing. Teams often create a single service record that is simultaneously technical and business-facing. This collapses the model and breaks the separation of concerns the CSDM is designed to enforce. The result is a hierarchy that cannot support proper impact analysis or meaningful reporting by audience.
Leaving relationships unmapped or partially mapped
Creating service records without connecting them through relationships is the most damaging structural error. A Business Service with no linked Application Service is an island. It cannot be used for impact analysis, it cannot surface in AI-driven recommendations, and it provides no operational value beyond documentation. Relationship completeness must be treated as a hard requirement, not an optional enrichment step.
Failing to enforce data rules consistently
Many teams define their CSDM structure correctly on paper but have no mechanism to enforce it in the platform. Records get created without required fields. Relationships get added inconsistently. Over time, the hierarchy drifts from the intended model. This is where a tool like Data Content Manager adds real value: it lets teams define and enforce data model rules natively in ServiceNow, without scripting, so that every record created against the CSDM structure meets the defined completeness and relationship requirements before it causes downstream problems.
Getting the CSDM service hierarchy right is fundamentally a data discipline problem as much as it is an architectural one. The structure itself is well defined by ServiceNow. The challenge is keeping that structure intact as the platform scales, teams change, and data accumulates. If you want to see how enforcing CSDM data rules works in practice, get in touch and we can walk you through it.
