Adopt and govern CSM progressively
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.
CSM adoption is an operational practice. The whitepaper recommends Establish, Connect, Govern, and Measure and improve. These stages guide priorities; they are not system feature flags, subscriptions or an implemented maturity score.
Before you start
Nominate owners for Services, Offerings, applications, configuration, assets, catalog work and measurements. Governance responsibilities are not necessarily dedicated application roles. One person may carry several responsibilities but still needs the appropriate permissions.
Steps
- Establish one representative Service with accountable ownership, a usable default Offering, team, schedules and priority targets. Demonstrate a correctly routed Incident and Request.
- Connect critical Business Applications, production Instances and CIs where useful. Review dependency direction and impact semantics with technical owners and test a failure scenario.
- Govern Catalog approvals, Change controls, Asset references and reconciliation. Demonstrate traceable onboarding, maintenance or repair work.
- Measure and improve using sampled SLA records, explicit Outages, quality checks and reporting reviews. State measurement scope and limitations alongside results.
- Expand only when record maintenance has an owner and the connections serve real operational questions.
Data quality playbook
Review Services without owners or default Offerings; Offerings without suitable teams/schedules/targets; duplicate application identities; missing or contradictory Instance environments; unreviewed dependency direction; missing impact meanings; stale CIs; Asset–CI mismatches; incorrectly routed Catalog actions; and unreliable Outage timestamps.
A practical exception register can record issue, severity, owner, discovery date, agreed remediation, accepted exception and review due date. This is recommended governance; a dedicated native CSM exception register or automatic completeness score is not asserted.
Model changes and retirement
For a new entity interpretation or relationship role, document the business question, owner, valid endpoints, cardinality, identity, lifecycle, environment, access, authoritative fields, consuming rules and compatibility. Test migration and rollback before changing meanings used by integrations or reports.
Before retirement, identify dependent Tickets, Catalog Items, policies, relationships, Outages and historical references. Preserve traceability and coordinate with the domain owners. Deletion can orphan scalar references, so do not treat it as a universal replacement for controlled retirement.
Acceptance evidence
Retain representative ticket numbers, screenshots, reviewer decisions and deviations. Check normal Offering routing, configured technical overrides, PROD/TEST boundaries, non-impact edges, redundant-member scenarios, request approvals, Change authorization, asset return and inventory discrepancy handling. Verify tenant isolation and appropriate ordinary-user visibility.
Expected result
Owners can demonstrate that the model answers real operational questions and know who will maintain the data after initial setup.
Important behaviour
An ITSM Lite tenant can be well governed; a CSM Full tenant can have unreliable configuration data. Enabling a view does not establish model completeness, discover resources or validate the dependency map automatically.