Model dependencies and interpret impact
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.
Configuration relationships explain how resources participate in delivery. Relationship type describes the connection; impact mode describes how a failure may propagate. They are separate decisions.
Before you start
Use CSM Full with Configuration Management enabled and appropriate rights. Identify a technical steward and one real scenario to validate. Focus first on important production dependencies rather than collecting every discoverable component.
Steps
- Find or create the correct CI and Instance identities, checking environment and ownership.
- Select source, target and relationship type. Examples include Runs on, Hosted on, Depends on, Connects to, Uses, Contains, Member of, Load balanced by, Database for, Supports and Delivered by.
- Select the impact mode explicitly. Use No automatic impact for descriptive associations that should not propagate failure.
- Walk a concrete scenario with the technical owner: if this database fails, which deployment may be affected, and why?
- Review direction, alternative paths and redundant members. Correct the graph before trusting its conclusions.
- Test an Incident with the relevant Primary CI and inspect potentially impacted Instances/Offerings. Confirm real user impact separately.
Interpret impact modes
Hard dependency describes a failure that can make a dependent unavailable. Soft dependency expresses possible impact without certain outage. Degradation only describes reduced capability. Redundant member and Quorum member represent membership-related resilience. No automatic impact keeps an edge descriptive for automatic traversal.
The documented Incident traversal is cycle-safe and capped at ten hops. Redundancy/quorum uses a simplified all-siblings-down assumption, not configurable partial quorum calculation. A conceptual quorum relationship is therefore not a promise that the runtime evaluates every threshold design.
Routing is a different calculation
Normal Incident assignment comes from the selected Offering. An explicit enabled Primary-CI override can take precedence; otherwise a documented one-hop parent Instance override can apply. That one-hop routing lookup is different from the multi-hop impact traversal. A CI is not mandatory simply to obtain a support team.
Expected result
Technical impact is explainable from reviewed relationships and their meanings, and staff can distinguish a predicted consequence from a confirmed disruption.
Important behaviour
Missing edges, reversed direction and stale records can produce misleading results. Potential impact does not create an Outage or prove downtime. Availability propagation has different redundancy and aggregation limitations from Incident impact; do not reuse an impact result as a measured availability percentage.