A CSDM model needs to make a real service-impact question answerable. Consider a customer-facing ordering service whose application instance runs on two hosts. A useful model distinguishes the business application, application service or service instance, business service, service offering and the infrastructure relationships needed for incident and change impact. If an offering has no valid service path, a diagram can appear complete while the dependency that matters to the service owner is missing. Independent CIS-DF CSDM mapping practice cases can exercise correct domain and relationship choices, but they are not official ServiceNow certification questions. The implementation should verify the current supported CSDM relationship types and prove that the expected service appears in a bounded impact query.
Imagine a fictitious regional bank introducing an instant-transfer service. Product leaders plan the capability, architects select an application, developers build it, platform teams operate several runtime components, and customers consume a published transfer service offering. Each group describes a different aspect of the same product. If everything is recorded as one CI called “Transfer,” the CMDB cannot explain which actual component failed or which offering should appear in a customer portal.
Begin with the CSDM lifecycle rather than a table-name quiz
Current ServiceNow CSDM domain documentation organizes the conceptual model across Foundation, Ideation & Strategy, Design & Planning, Build & Integration, Service Delivery, Service Consumption and Manage Portfolio. The model places service and product information along a lifecycle, with portfolio management spanning domains. Those names are useful, but they are not enough to choose an appropriate CI or relationship under a real scenario.
For the bank, start with a simple timeline: an idea is proposed, assessed, designed, built, released as a running service and consumed by a customer. Then place an accountable role alongside each stage. Ask what each person needs to find: an approved investment concept, a business application’s planned capability, a deployed service instance, a technical support offering, or a customer-facing catalog item. The answers produce a mapping plan that can be reviewed against the official model.
Foundation provides reference data, not a substitute CI graph
The Foundation domain supplies base information referenced across other domains, such as organizations, groups, locations and relevant product reference records. These are prerequisites for coherent ownership, reporting and lifecycle processes. ServiceNow explicitly distinguishes foundation reference tables from configuration-item relationships. An office location can be associated with a CI without being an operational dependency of the same kind as a database hosted on a server.
Build a small reference set for the bank: legal entity, service owner group, support organization, location hierarchy and product model. Assign them to the right business or technical records. Validate parent relationships in organization or location hierarchies before interpreting reports. A platform with missing support groups can contain detailed CI attributes and still struggle to route incidents, while inconsistent location references can fragment global reporting. Fix the reference-data problem before adding artificial service relationships to compensate.
Ideation and Design & Planning represent intent
Ideation & Strategy records business concepts and improvement intentions rather than describing deployed servers. Design & Planning contains information used by enterprise architects and digital product owners to plan what will be built or bought. A proposed payment capability and a business application representing the architectural design are not the same as an active application-service CI supporting a production workload. Maintaining that separation makes portfolio questions answerable without polluting operational monitoring views.
Suppose the bank considers two payment-provider options before making a decision. The planning objects can represent those alternatives and the capabilities they might enable, without creating imaginary live dependencies in the production CMDB. When a provider is selected, the design can be linked to actual implemented applications and later operational records through approved model relationships. ServiceNow’s Design & Planning domain documentation emphasizes business applications and related planning entities. Use those objects to show what the organization intends, not to claim a service is already running.
Build & Integration records the development contribution
Build & Integration supports development teams and their work connecting an approved design to a deployable product. The Build & Integration documentation discusses Agile development components and their relationship to business applications and service instances. Not every implementation must populate every optional development object immediately; scope the model to the tools and supported capabilities the enterprise actually uses.
The bank might track an internal transfer module in a development process while operations observes three deployment instances. A developer’s logical component is not a fourth running server. Connect the model appropriately if the organization has the necessary relationships and ownership, so a production change can be traced back to a development capability without confusing planning and operational state. During implementation, use one well understood product path as a pilot before scaling the modelling conventions across unrelated applications.
Service Delivery connects runtime components to technology services
Service Delivery represents the infrastructure and operational service information that makes an offering possible. A runtime application-service instance, technical service or technology management offering plays a role in operations, change impact and ownership. Those records should connect to relevant CIs and service dependencies under the intended relationship types. The structure enables a change manager to ask which service instances depend on a database or which team operates an affected technical capability.
For the bank’s transfer application, record a service instance representing the runtime application environment and connect it to the required application components and database CIs using verified relationships. An ownership or support group relationship should not be inferred from a network scan alone; it may require operational approval. The target is a service graph that can survive an outage investigation, not a drawing that merely looks connected. Test it against a known failure path and explain any missing or uncertain edges.
Service Consumption expresses what customers can request or experience
The Service Consumption domain models internal or external services and offerings in the context of consumption. A business service offering such as “Instant Transfer — Business Customers” describes a consumer-facing promise, eligibility or support context, while the deployed service instances and technical dependencies live in the delivery model. A catalog item is an interface for requesting a service and should not be treated as a general CMDB CI just because it appears beside service objects in a conceptual diagram.
Create two offerings for the same transfer service: standard and high-priority support. They may depend on shared backend runtime service instances but have different customers, commitments and support processes. A failure in the shared database can affect both offerings, but the service desk may need to communicate distinct consequences. Correct relationships give this traceability; duplicating the entire infrastructure graph once for each offering introduces unnecessary complexity and more room for stale records.
Manage Portfolio links ownership across domains
Manage Portfolio overlays the lifecycle by helping service owners and portfolio roles manage products and services across the other areas. An owner may need to see both planned enhancements and current operational performance. That does not imply every record has the same owner or that portfolio data automatically overrides runtime identification rules. A coherent model connects strategic responsibility with delivery accountability while preserving which system owns each fact.
For a bank product leader, a portfolio view should clarify the product, its consumer services, planned enhancements and accountable people. For a platform engineer, the same product may be reached through a runtime service instance and dependent database. Link these perspectives through supported relationships and explicit stewardship. If an owner change is approved, verify which reference records and service definitions must change rather than rewriting every technical CI’s identity or forcing a new class to represent organizational structure.
Test domain mapping with a contested service scenario
Write a synthetic record set: one proposed transfer feature, one business application, one development component, two runtime service instances, one technical service, two service offerings, a customer group and three infrastructure CIs. Ask five stakeholders independently which records they need. A finance sponsor should not search a list of VM disk serial numbers to find planned business value; an incident responder should not use an idea record as the authoritative outage target. Compare each mapping to the official domain and relationship definitions.
A final modelling review should include a person outside the CMDB implementation team. Ask a service-desk agent to locate the customer-facing offering associated with a known outage, a developer to identify which logical component was deployed, and a portfolio manager to find the product owner responsible for the planned change. If all three people are shown the same generic CI record, the model has probably collapsed important distinctions. Record which question each domain successfully answers, then inspect the relationships that connect those answers. This exposes missing ownership and misleading links that a class-name-only exam rehearsal would never reveal.
A useful follow-up is to ask how the record model should react when the bank replaces its transfer application but retains the same customer-facing service offering. The operational service instances and software components may change while the consumer commitment persists. Distinguish the lifecycle of a planned business application from the instance deployed today, and preserve the relationships needed for historic change and incident analysis. If every product upgrade creates a new customer service offering, support teams may lose continuity; if every implementation shares one undifferentiated CI, impact analysis becomes unreliable. The model needs independent identities connected by approved relationships.
The distinction between a CMDB’s technical CIs and the Common Service Data Model’s business and technical service structures determines which stakeholder question a relationship can answer. The relationship between CMDB and CSDM helps separate raw infrastructure records from the application service and offering that a business user recognizes. In a validation exercise, retire a runtime service, remove the owner from a business application and leave an offering without the expected service relationship. A reliable model makes those gaps visible to the appropriate steward rather than hiding them behind one generic record called “Service.”