ServiceNow Common Service Data Model Best Practices

The Common Service Data Model, or CSDM, is a way of defining services with clear owners and boundaries, then mapping each one to the capabilities and infrastructure that support it. This page sets out the practices for definition, capability mapping, cost attribution and governance, plus a decision table and a pilot sequence for the first services.

The Common Service Data Model earns its keep when services are defined with clear owners and boundaries, mapped to capabilities and then to the infrastructure that supports them. The practices below cover service definition and ownership, capability mapping, service-to-infrastructure relationships, service measures, cost attribution, governance and data quality, followed by a decision table for modelling choices, a pilot sequence for the first services and the signals that show the model is drifting.

Practice 1: Service Definition and Ownership

Begin by clearly defining what constitutes a service. A service is something your organisation delivers to customers or internal users. Examples: email, HR applications, customer portal, billing system. Each service should have: a unique name and identifier, a clear description of what it does, an owning team or group, a list of customers (business units, user groups) who depend on it, and critical business information (SLA, cost, regulatory requirements).

Define service boundaries: what is included in the email service (only the email platform, or also storage and backup)? What is excluded? Ambiguous boundaries cause confusion when incidents occur. Document service definitions in a service inventory; this becomes the single source of truth for your service landscape.

Practice 2: Capability Mapping

Services are built on capabilities: the email service depends on a mail server capability, a backup capability, and a directory capability. Map services to capabilities in ServiceNow. This intermediate layer abstracts away specific infrastructure, so you can describe what the service does without getting into server-level details.

Example: the email service is built on the “Mail Delivery” capability, which is realised by a specific mail server (Exchange, Postfix, other). If you migrate to a different mail server, the capability remains the same, but the underlying CI changes. This separation makes service definitions more durable across infrastructure changes.

Practice 3: Relationship Definition Between Services and Infrastructure

Link each service to the infrastructure that supports it: which servers host this service, which databases store its data, which networks carry its traffic. In CSDM terms, a service “depends on” infrastructure CIs. These relationships enable impact analysis: when a server fails, which services are affected?

Be precise about relationship types: a service may “require” a database (it cannot run without it) or “use” a database (it reads data but is not critical to the service). ServiceNow supports relationship types; use them to reflect true dependencies, not just all possible relationships.

Practice 4: Service Metrics and KPIs

Tie service definitions to operational metrics. If email service SLA requires high availability availability, define what “availability” means (percentage of business hours when email is accessible, or percentage of calendar days). Set up metrics in ServiceNow that track this: availability percentage, mean time to recover, customer satisfaction. Link these metrics to the service record so stakeholders see how well the service is performing.

Practice 5: Cost Attribution

Allocate infrastructure costs to services. If a server costs 10,000 per year to operate and three services share it equally, each service is charged 3,333. CSDM enables this allocation: you define which services use which infrastructure, and a cost model distributes costs accordingly. This helps finance understand the cost of each service and helps business units understand their true technology spending.

Practice 6: Service Governance and Review

Establish a governance model: who defines services (usually the business owner), who owns the CSDM (usually IT architecture or service management), who has the authority to change service definitions. Define a review cycle: at least annually, review service definitions to ensure they are still accurate. As your organisation changes (new services launched, old services retired), update the service inventory.

Practice 7: Data Quality and Maintenance

CSDM is only useful if the data is trustworthy. Establish data quality standards: every service must have an owner, every service must be linked to infrastructure that supports it, relationships must be verified as accurate. Assign data stewards to maintain CSDM; this is usually the IT architecture team or a CSDM governance board.

Run periodic audits: sample services and verify that the mapped infrastructure is correct and complete. If a service’s infrastructure has changed (a server was retired, a new server was added), update the service mapping. If completeness or accuracy is below target (for example, below target), launch an improvement initiative.

Deciding Where One Service Ends and the Next Begins

Many CSDM projects stall in the first month, not because of tooling, but because two people describe the same thing differently. The CMDB lead thinks of a service as the platform that runs a business function. The application owner thinks of it as their application. The finance lead thinks of it as the thing that gets a monthly charge. All three are right for their own purposes, and CSDM can hold all three, but only if the team agrees which layer each name belongs to before anyone creates a record. A practical starting point is to separate what the business buys, what the platform team operates, and what runs underneath. Those three layers often correspond to a business-facing service, a technical service or offering, and the application instances and infrastructure that deliver it.

Once the layers are agreed, the boundary question becomes concrete. Take a payroll service. Does it include the time-entry front end, the interface that sends data to the bank, and the reporting database? If the time-entry tool is owned by another team and has its own service record, then payroll should depend on it rather than contain it. Write that rule down. Otherwise the same server can end up under two services and the impact analysis reports double.

Decision Table for Modeling Choices

The choices below come up often in CSDM work. The right answer depends on what the model is for, so the table records the conditions that favor each side.

A Pilot Sequence for the First Five Services

1. Pick services that have an owner who replies to requests promptly. A pilot with an absent owner can produce records nobody will defend later.
2. Write a one-paragraph definition for each service that states what is in and what is out, and get the owner to sign it.
3. Map the technical layer first, then the application instances, then the infrastructure. Mapping in the reverse order invites guessing at the middle layer.
4. Run one impact analysis by hand: choose a single component, list the services you expect it to affect, and compare that with what the model returns.
5. Fix every disagreement in the definitions before scaling. Each disagreement you carry forward multiplies across every service that follows.

The relationship types you choose matter as much as the records. A service that cannot run without a database should be linked as a hard dependency. A service that only reads from a reporting copy should be a softer relationship, and the difference should be visible in the model. If every link is a hard dependency, a single reporting outage can light up every service in the impact view.

Signals That the Model Is Drifting

A CSDM that is going wrong often does not announce itself. The early signs are operational. Incident records arrive with a service field that is blank or set to the name of a server. Change requests list services that were retired long ago. Two services show the same infrastructure with different owners. Each of these is a data-quality defect that someone will eventually need to act on, and the fix is cheaper when the first instance is logged. Keep a short register of these signs and review it at the same cadence as the governance meeting, so drift is handled as a normal item rather than a crisis. For who should chase each defect, see the roles and RACI guide.

When Not to Model a Service Yet

Hold off on a service when no one has agreed its owner, when its boundary depends on a project that has not finished, or when the only reason to create it is to make a report look complete. A service that exists on paper but has no owner and no mapped infrastructure can look healthy in dashboards while it is in fact unmanaged. It is better to leave a gap in the model, record the gap as a known item, and close it when the conditions are met. The first release scope approach describes how to decide what waits for a later phase.

Frequently Asked Questions About CSDM Best Practice

Should every application be a separate service?

No. An application is often part of a larger service the business recognizes. Treat the application as a component when the business never asks about it separately, and as its own service only when it has its own owner, its own SLA, or its own cost line.

How do you handle a shared platform such as a message queue?

Model the platform as a technical service that several business services depend on. Give it a single owner, and make each dependent service’s link explicit. That way a change to the platform shows its full reach, and fewer teams are surprised by a dependency they did not know they had.

What is a sensible review rhythm for service definitions?

Review definitions when something structural changes, such as a launch, a retirement, a change of owner, or a migration. In addition, schedule a periodic review that checks the register of drift signs. The schedule depends on how often services change in your organization, so set it from observed change rather than from a fixed calendar.

Can a CSDM be built without discovery?

It can, but it often depends heavily on interviews and documentation, and the model can go out of date sooner. Discovery is valuable for the infrastructure layer because it keeps the lower layers current, while the service definitions still have to come from people.

Next Step for Your CSDM Practice

For the wider picture, the starting point for business services post covers the first decision in more detail.