The Common Service Data Model links portfolio planning, business applications, deployed service instances, infrastructure and consumer offerings without making those objects interchangeable. ServiceNow’s seven-domain CSDM 5 framework gives those records distinct stewardship and lifecycle contexts. The ServiceNow CIS-DF CSDM Fundamentals objectives test whether an implementer can place records and relationships where downstream service operations will actually use them, not merely label everything as an application.
CSDM 5 describes seven domains: Foundation, Ideation & Strategy, Design & Planning, Build & Integration, Service Delivery, Service Consumption, and Manage Portfolio. Their value is not the number of boxes on a diagram; it is a shared decision model from planning through operation and consumption. For a university’s online registration service, identify who maintains the business application, the production service instance, its enabling technology and the consumer offering before deciding where each record belongs.
Foundation carries reference data for every other domain
Foundation includes information used by many other parts of the model: organizational data, groups, locations, product models, contracts and other references. Poor Foundation data propagates into confusing reports and assignments. A server with the wrong location or an offering with no clear support group may be technically discoverable yet operationally unreliable. That problem is different from discovering more CIs; it requires valid shared reference information.
For the university, a campus location, organizational unit and product model may be maintained by different stewards. Agree who owns each and how changes are approved. If teams independently create duplicate names for the same campus or software product, services can appear to belong to separate organizations when they do not. The Data Foundations dashboards can expose missing foundational relationships, but the business has to repair its reference-data governance.
Ideation & Strategy concerns what might be built
The Ideation & Strategy domain captures early concepts, goals, planning items and decisions before a service exists in production. A proposal to replace the university’s registration portal is not the same as a deployed registration service. It belongs in planning and strategy work until it becomes a defined architecture and implementation effort. Recording every proposed initiative as an operational CI would distort incident and change populations.
Consider three competing proposals: improve the existing portal, buy a hosted student system or build a new application. Product and business stakeholders compare the value, risk and scope of these ideas. Service operators are not expected to troubleshoot a database for an option that has not been selected. Clear separation lets the organization retain a trace from early decisions to later applications without manufacturing technology records prematurely.
Design & Planning describes the intended business solution
Design & Planning includes business capabilities, business applications and information objects used by enterprise architects and product owners. A business application is a logical portfolio-level representation of the software supporting a capability; it is not necessarily a live production service instance. The ability to register students, for example, may rely on a portal application and an information object representing enrollment details.
Those design records answer planning questions: Who owns the application portfolio? Which capabilities does it support? What is the intended lifecycle or information domain? They do not tell an on-call engineer which database failed at 2 a.m. CI classification and relationships determine how semantics and class choice affect downstream data. Avoid making an application-service record do double duty as the entire enterprise portfolio model.
Build & Integration links design with delivery work
Build & Integration represents work and artifacts involved in developing and integrating digital products. The university may implement APIs, service interfaces, development components and deployments before a student-facing service is available. Different objects describe code and integration lifecycles rather than directly representing end-user consumption. Make that distinction explicit so a development dependency is not automatically treated as a live operational outage path.
A new identity-service API might support multiple applications. Its architectural interface can be related to the broader design, while an actual running endpoint participates in a deployed service context. Both kinds of information matter but answer different questions. Decide how teams record and approve transitions from design to live service, then validate them with a small set of real implementations instead of attempting to map the entire software-development system in one project.
Service Delivery shows operational capabilities and instances
Service Delivery represents the technology and service instances that make a solution function. A deployed registration application service can have relationships to hosted compute, data stores, integration services and network components. This is where incident and change impact become particularly meaningful. When the university’s enrollment database fails, operators need to identify the affected production service and responsible support team, not merely the portfolio application name.
An application service and a business application should be related appropriately but not collapsed. Production and testing deployments of the same logical business application can have different underlying CIs and service-impact paths. With accurate relationships, Unified Map dependency analysis can trace the operational consequences of a production service failure without conflating the service with its application record. A false or missing relationship is an integrity issue to resolve at the model or source, not a reason to invent another “registration app” class.
Service Consumption explains what customers receive
Service Consumption deals with the services and offerings people use or request. For the university, students and departments might consume a student registration service with defined hours of availability and support expectations. Service offerings can distinguish tiers, regions or options; those consumer-facing promises are not the same as the servers and deployed service instances delivering them.
A service may have multiple offerings while sharing an underlying application service. Conversely, one offering could depend on several technology components. Model these relationships so incident responders and service owners can explain the consequence of a technology failure in customer terms. A portal menu item or catalog request alone is not sufficient evidence that a complete service instance has been modeled. The service needs a clear owner and a defensible path to operational dependencies.
Manage Portfolio connects decisions across the lifecycle
The seventh CSDM 5 domain, Manage Portfolio, provides a portfolio-level view across domains for owners who manage investment, risk and lifecycle decisions. It is distinct from the everyday relationship map used during an incident. Portfolio managers need to know which applications and services support a strategic outcome, which products are redundant, and where modernization effort should go. Their decisions span proposed, designed and operating states.
For the university, a proposal to retire the old registration portal might affect business capabilities, contracts, operational application services and consumer offerings. A portfolio view helps coordinate that work without replacing the CMDB’s technical identity and relationship rules. It is useful precisely because each contributing object has a defined purpose; if the same record ambiguously represents a product, deployment and service offering, portfolio reporting will amplify the confusion rather than resolve it.
Map stakeholders to the objects they can verify
A business architect can approve the capability map while an application owner approves a portfolio application, a service owner confirms offerings, and an operations team validates deployed application services and their technical dependencies. None of those roles alone has authoritative knowledge of every object. Assign stewardship where the evidence lives and design explicit handoffs where domains meet. This reduces the temptation for a single CMDB administrator to invent missing business context.
A simple ownership workshop can follow one user journey: student registration. Ask each stakeholder to identify the object they rely on, the person who should maintain it and the evidence for its relationship to the next object. If a team cannot say who owns an association, that gap is a modeling risk. The CMDB Workspace stewardship approach provides a governed route for cleaning up ambiguous operational records.
CSDM 4 terms are not interchangeable with CSDM 5 names
Earlier CSDM training materials may show groupings labeled Design, Build, Manage Technical Services and Sell/Consume. These labels cannot simply be substituted for the seven-domain CSDM 5 model without checking the underlying records and the release-specific guidance. Review the current mappings and their use in incident, change and portfolio workflows before moving or renaming existing CIs; preserve valid relationships and test a representative service before a broader transition.
Do not rename production classes or bulk-move existing CIs simply to make the interface resemble the latest CSDM diagram. Compare the installed release, current relationships and downstream processes against CSDM foundation principles. Stage changes in a representative service, preserve incident and change references and validate the behavior of connected ingestion before expanding the migration.
Build a minimum viable CSDM for a real service
Start with one valuable application and work from its current state. Confirm foundational owner and location references, a business capability and logical business application, a deployed application service and the consumer-facing offering. Record what each team can verify. Add technically supported relationships for the application instance, then check incident and change scenarios. A small, coherent model is more useful than thousands of incomplete objects created for presentation purposes.
Measure progress by decisions the model supports: can an incident be assigned correctly, can a change assessor identify impacted services, and can an application portfolio owner find the deployed instances of a retiring product? CSDM Data Foundations indicators can reveal missing information at different maturity stages. Do not treat high object counts as evidence of maturity without checking those operational questions.
Diagnose a misclassified university service
Suppose the CMDB contains one generic “Student Registration App” CI used by the portfolio team, service desk and infrastructure integration. Operators attach server relationships directly to it; planners record future investment changes in the same fields; service owners add consumer support hours. The record now changes for unrelated reasons and cannot explain which deployed service instance actually failed during an outage.
Separate the logical business application from deployed application-service instances and consumer offerings through a controlled modeling decision. Preserve existing incident and change references, identify authoritative owners, correct relationships and validate data ingestion before bulk changes. The CI Class Manager article outlines classification safeguards. The goal is to preserve truth and improve traceability, not to overwrite history or create a perfect-looking model that only the implementation team understands.
Choose CSDM objects for the question being answered
Exam questions may describe early strategy, application portfolio design, integration work, service operations or an end-user offering. Map the object and stakeholder to the relevant CSDM domain, then ask which relationship links it to the next stage. For example, a proposed modernization initiative is not a production application service, and a consumer service offering is not the same as a technical CI hosting its implementation.
Use the question being answered to select the right model object. An enterprise architect asking which business capabilities depend on a registration application needs the logical portfolio and application relationships. The on-call service owner asking which deployed component is causing failures needs the service instance and its operational dependency map. A student using an online enrollment offering asks which consumer service is available, not which internal CI provides storage. ServiceNow's CSDM 5 domain separation supports these different decisions; the same system may be represented by several related records because the questions are genuinely different. Test the model by asking one stakeholder in each role to locate the responsible owner and a concrete dependent record. If every question points to a single generic 'application' record, the model may be full of data but poor at preserving meaning.
Practice drawing one end-to-end example with a product idea, business capability, business application, running application service, key infrastructure dependencies, service offering and lifecycle portfolio decisions. Label each object’s owner and authoritative evidence. Add one real failure scenario and trace its impact. That simple exercise develops a much stronger grasp of CSDM than memorizing tables without understanding what each domain is for.