ServiceNow Common Service Data Model: Guides and Services

What Common Service Data Model Covers on the Now Platform

Common Service Data Model (CSDM) is a data structure that enables ServiceNow to model services, the technical and organizational components that deliver them, and the dependencies between components. It answers questions like: what technical infrastructure supports this business service? If an application fails, which services are affected? Which configuration items (servers, applications, databases) matter for my business and which are peripheral? CSDM provides a unified data model that works across ITSM, ITOM, and business-level service concepts, replacing the older approach where IT and business had disconnected views of services.

CSDM is a foundational data structure in newer ServiceNow releases; many ITSM and business analytics features depend on well-organized CSDM data. It enables impact analysis, change risk assessment, and intelligent incident routing based on business context.

How CSDM Relates to the CMDB and Service Portfolio

The CMDB (Configuration Management Database) holds the technical infrastructure: servers, applications, databases, networks. The Service Portfolio describes the services offered to the business. CSDM unifies these: it defines how services are composed from technical components and how services are aggregated into larger business capabilities. A business service like “Customer Billing” might depend on an “Invoicing Application,” which runs on three servers, a database, and a network link. CSDM defines these relationships so that impact analysis, asset management, and incident correlation can operate on this unified view.

How to Use this Section

Start by assessing the current state of your CMDB and service model. Do you have a clear inventory of applications and infrastructure? Can you trace which infrastructure supports which business services? Is this information scattered across multiple databases or systems? These questions inform your CSDM implementation strategy.

Build CSDM in phases. Phase one: clarify your business services (what services does the organization provide?) and the major applications that deliver them. Phase two: map applications to infrastructure components (servers, databases, networks). Phase three: implement discovery so that infrastructure is continuously synchronized into the CMDB. Phase four: use CSDM for impact analysis, change management, and incident correlation to improve operational decision-making.

Design CSDM carefully. It is easier to get right initially than to refactor later. Engage business stakeholders (service owners), application teams, and infrastructure teams in defining the service model so that it reflects how work actually gets done, not just IT abstractions.

Typical Starting Problems

Organizations often have strong infrastructure visibility (CMDBs full of servers) but weak service-level visibility (hard to say which infrastructure supports which business service). Impact analysis and root-cause analysis are manual and error-prone. Incident resolution teams don’t know which infrastructure matters for a business service and waste time investigating peripheral components. Change managers cannot assess impact without detailed manual analysis. CSDM implementation provides the clarity needed for efficient incident response, change management, and strategic IT planning.

What Oblytech Provides

Oblytech helps design a service model aligned to your business strategy and organizational structure, build CSDM data by discovering infrastructure and mapping it to services, implement impact analysis and change risk assessment based on CSDM relationships, and train teams to use CSDM for more effective incident response and change management. We help you assess the quality of your current CSDM and improve it through data validation and enrichment.

CSDM implementation is iterative. You don’t need a perfect model on day one. Start with core business services and the applications that deliver them, then expand gradually. As you build CSDM relationships, impact analysis becomes more effective: you can trace a failing component back to affected services and know which customers are impacted.

CSDM is also used for cost allocation and chargeback. By linking infrastructure costs to services and services to business units, you can show departments the true cost of the services they consume. This enables chargebacks and encourages optimization.

Choosing where to start, based on the question you are trying to answer

The Common Service Data Model covers a lot of ground, and the right first step depends on which question is hurting most. A team that cannot say which business service a failing server supports needs service mapping before anything else. A team whose service list is itself disputed needs a decision about scope before any mapping is attempted. A team that already trusts its service list but never checks its relationships needs validation, not new data. The table gives a practical route for each situation.

The reason for the table is that the data model rewards sequence. Each layer assumes the one beneath it is trustworthy, so the cost of getting the start wrong grows with every service added on top.

What a service record has to carry to be useful

A service record is not a label. It is the anchor for ownership, support routing and impact questions, and it only works when a small set of fields is consistent across services. Before any record is created, agree the fields that every service must carry and the ones that are optional. A useful minimum includes the business owner, the technical owner, the support group that receives incidents, the hours of service, and the items that deliver it. Fields that differ by service should be explained rather than left blank, because a blank field is indistinguishable from a field nobody has yet answered.

The support group field deserves particular care. It is the value that drives automated routing, and it is the one that is often copied from an out-of-date organization chart. Confirm it against the people who actually answer the phone or the queue, not the team name in the directory. The assignment groups guidance covers how those groups should be kept current.

A mapping sequence that keeps the model honest

1. Write down the business services in plain language, using the names customers and colleagues already use, and remove any that are really internal tools.
2. Assign one business owner and one technical owner to each service, and confirm both by asking them to describe the service in their own words.
3. Map each service to the applications it depends on, then to the infrastructure those applications run on. Mark any link that is inferred rather than confirmed.
4. Validate the inferred links with the people who run the applications, and record the date and the person who confirmed each one.
5. Only then turn on automated relationship discovery for the mapped items, and compare what it finds with the validated set before accepting any new links.

Step five is where many programs go wrong. Automated discovery is fast and confident, and it can happily propose relationships that are technically possible but operationally meaningless, such as a shared monitoring agent linking every service to a single host. Review the proposals rather than accepting them in bulk.

Common ways a service model goes wrong

The first failure is mapping services to the organization chart. Teams become services in the model, so an incident about a shared platform is routed to whichever team is named, not to the team that owns the failing component. The second is defining too many services. A catalog of many fine-grained services is harder to maintain than a few well-defined ones, and every entry in it requires a named person who is accountable for its upkeep. The third is treating an application and a service as the same thing. An application can support several services, and a service can depend on several applications. Keeping those separate is what makes impact analysis useful.

A fourth failure is leaving the model to age. Services are retired, renamed and merged, and the relationships that described them go with them. Build a review point into the change process so that a change to a service’s components prompts an update to its record.

Questions people ask before committing to the model

Should every application become a service?

No. Applications that only support one service are often better described as components of that service. Make a service only when a business owner would recognize it as a thing the organization offers or relies on.

Can we model services before the CMDB is clean?

Yes, as long as the services are kept separate from the infrastructure data and their relationships are marked as unvalidated until checked. Presenting an unvalidated model as settled can quickly cost the service owners their trust.

How do we decide how detailed the model should be?

Let the decisions drive the detail. If the model is used to route incidents, the level of detail should match the routing rules. If it is used to explain cost, it needs the links to cost centers. Adding detail that no decision uses only adds maintenance.

Who should sign off a new service definition?

The business owner should approve the definition, and the technical owner should confirm the components. The adoption and training plan covers how those owners are brought in before the first dashboards go live. Keep both approvals on the record so that a later dispute about what a service includes has a clear starting point.

Next step

Once the first services are agreed, the requirements workshop questions help draw out the rest, and the CMDB guides cover the infrastructure side the model depends on.