Select impact modes and inspect the dependency map
Configuration Management enabled, CSM Full and relevant staff permissions. CI and relationship writes require administrator rights; application permissions differ.
Impact mode is the critical second dimension of a CI relationship. It describes how a failure may affect a dependent resource. Relationship type describes what the connection means. Neither a map line nor the word DEPENDS_ON proves an outage.
Before you start
Identify a technical steward and a controlled scenario. Confirm active records/edges, environment, stored direction and whether automatic impact analysis is enabled for the intended use.
Steps
- Choose the relationship's intended failure semantics using the modes below. The default is No automatic impact.
- Inspect direct neighbors, upstream/dependent resources and downstream/required components from the selected CI.
- Follow the relevant Instance and Offering context without treating their associations as equivalent to technical dependency edges.
- Test a known component failure and inspect the potentially affected records. Investigate both missing and implausible results.
- Confirm actual user effect separately and record an Outage where there is observed disruption.
Six supported modes
HARD_DEPENDENCY means a failure can make the dependent unavailable, such as a single essential database with no viable fallback.
SOFT_DEPENDENCY means potential impact without a certain outage, such as an optional integration that needs human assessment.
DEGRADATION_ONLY means reduced functionality or service quality rather than necessarily total unavailability.
REDUNDANT_MEMBER models membership where other functioning peers can tolerate some failures.
QUORUM_MEMBER identifies membership-related operation, but the documented calculation does not implement configurable partial quorum thresholds.
NO_AUTOMATIC_IMPACT keeps the relationship for descriptive context while skipping it in automatic impact traversal. It is appropriate when monitoring supports an application but monitoring loss does not stop the application.
Cluster example and algorithm limits
A Portal may have a hard dependency on a database cluster, while the cluster-to-node connections represent redundant/quorum membership. Losing one node should not automatically imply total Portal failure.
Incident propagation uses an all-siblings-down simplification for redundant/quorum members. It is not a complete simulation of a three-node majority quorum. Availability propagation excludes redundant/quorum descendants rather than calculating partial peer failures.
The documented impact traversal is cycle-safe and capped at ten hops. Missing edges, incorrect direction, inactive records and environment mistakes can affect results. Reaching the cap does not mean the whole enterprise graph was analyzed.
Expected result
Staff can explain why a record appears potentially impacted and where the model or algorithm requires human judgement.
Important behaviour
Incident assignment's parent Instance override lookup is only one hop; dependency impact traversal is a different calculation. Predicted impact is not confirmed downtime, an SLA breach or measured availability.