Distinguish CSM entities and relationships
Read access to this guidance; editing requires the applicable module, operating view and record permissions.
Understand the model behind the workflows.
Download the original Connected Service Model whitepaper, version 1.0, dated 2 October 2026. Its 25 pages cover principles, conceptual and system models, six domains, relationship semantics, governance and adoption.
The PDF is the original proposed reference baseline. Online guidance includes later implementation clarifications; model recommendations do not establish automatic product enforcement.
A useful model separates meanings before connecting records. Similar names do not imply shared identity, lifecycle, authority or automatic behaviour.
Before you start
Choose a representative service and write down the question each record answers. Use stable identifiers and meaningful environment labels. Search for existing records before adding another representation of the same resource.
Steps
- Name the Service for the outcome, for example Employee Collaboration. Use an Offering such as Business Hours Support for a specific scope and support commitment.
- Use Employee Portal as the Business Application identity. Use Employee Portal PROD and Employee Portal TEST as distinct deployed Service Instances.
- Represent the operational database, server and network components as CIs, with reviewed directed relationships.
- Associate the Offering and Instance using Delivers Offering, Supported by Offering or Managed through Offering according to the intended meaning.
- Create Request Portal access as a Catalog Item. Keep its intake, approvals and Tasks in request configuration rather than assuming they belong to the Offering.
- Keep laptop AST000123 as an Asset with custody and commercial history; optionally connect it to the operational CI.
- Keep Contacts, Tickets and Outages distinct: conversation, formal work and observed disruption respectively.
Cardinality and identity
A Service can have several Offerings, and each Offering belongs to one Service. The selected default must belong to that Service. A Business Application can have several Instances. A Service Instance is a kind of CI and shares the CI identity; it is not a second name for the application portfolio record.
Offerings and Instances have a many-to-many association: one deployment can participate in several commitments, and one Offering can use several deployments. Keep the role explicit rather than cloning the deployment for each support package. Role semantics do not by themselves prove that every consuming algorithm treats those roles differently.
An Asset may optionally reference a CI. Current scalar links can become orphaned, and several Assets can reference the same CI; reconciliation helps review those conditions rather than establishing automatic one-to-one integrity.
Lifecycle and authority
Retiring a technical Instance does not automatically retire its Service or every Offering. Asset retirement does not automatically establish the CI's operating state. A support-team change is different from a change of accountable owner. Review each domain's own authority and lifecycle.
Expected result
A shared deployment is represented once with explicit relationships. Service definitions, request actions, custody and work retain their distinct meanings.
Important behaviour
Service hierarchy is portfolio organisation, not an implicit technical dependency graph. An Offering–Instance association is not an impact edge or a health measurement. The whitepaper describes the conceptual model; confirm the relevant UI/API consumer before relying on automatic behaviour.