Skip to main content
© nowXperts. All rights reserved.

CSDM Is Not a Data Model Project. It Is the Precondition for AI

Why the Common Service Data Model in ServiceNow moved from housekeeping exercise to a hard requirement for putting AI to work.
August 7, 2026

Few topics have been deferred as reliably in ServiceNow programmes as the Common Service Data Model. The reasoning was understandable. CSDM looked like a modelling exercise with no visible outcome: lots of workshops, lots of tables, and at the end the service desk works exactly as before. The benefit sat in the future, the effort in the present.

That calculation no longer holds. Not because the model improved, but because who reads the data has changed.

People compensate for gaps. Agents do not

An experienced service desk analyst does not need a clean CMDB. They know the application appears under three different names, that the record has been wrong since the last data centre move, and who you actually call about that system. None of this is written down anywhere. It has been quietly compensating for what the model lacks for years.

An AI agent has none of that knowledge. It reads what is there. If the service is not linked to the application, it cannot find the connection. If no owner is recorded, it escalates into nothing. If lifecycle state is not maintained, it treats a decommissioned system as production.

A data quality issue has become a functional issue. The gap in the model is no longer inconvenient. It is limiting.

What an agent actually needs from the model

The instinct to respond by building a complete CSDM leads straight back into the same deferral loop. The more useful sequence runs the other way: derive the required model from the intended use cases.

An agent that routes incidents to the right group needs the link from configuration item to application service and from there to the responsible group. It does not need a fully modelled catalogue of business capabilities.

An agent that assesses change risk needs reliable dependencies between services and criticality on the affected systems. It does not need modelled contractual relationships.

An agent that serves knowledge needs maintained articles with a clear service reference and a validity state. It does not need discovery across the entire infrastructure.

Seen this way, CSDM becomes plannable. Not as an eighteen month programme, but as a sequence of small, verifiable increments, each unlocking a specific use case.

The cost of waiting has changed

A thin model used to cost reporting quality. Metrics were imprecise, service costs hard to allocate, the portfolio blurry. Annoying, rarely urgent.

Today a thin model costs automation. Every use case that fails on missing relationships stays manual. And since AI capabilities now sit inside the licence tiers, the company pays for them regardless of whether it can use them.

There is a regulatory dimension too. Traceability assumes an automated decision can be tied back to a defined service, a defined system and an accountable owner. That mapping is exactly what the model provides. Without it, evidence becomes a reconstruction from log files.

A pragmatic way in

Three steps are enough to break the deferral.

Take stock without judging. Which layers of the model are genuinely populated today and which exist only as an empty table? This takes days, not weeks, and settles most of the debates before they start.

Pick two use cases. One with high volume, one with high risk. That determines which slice of the model is needed first.

Anchor maintenance permanently. A model built during a project and left alone afterwards is inaccurate again within two releases. Ownership, discovery and lifecycle rules belong to operations, not to implementation.


CSDM was an architect’s topic for a long time. It is now everyone’s topic wherever automation is expected from the ServiceNow platform. The difference between an agent that works and one that disappoints rarely lies in the AI model. It lies in what the agent finds.