4.3 Relationship-Driven Impact Analysis

In modern enterprises, infrastructure components do not operate in isolation. A failure of a single physical server can cascade, affecting virtual hosts, application instances, middleware, and ultimately critical business services. Relationship-Driven Impact Analysis is the platform logic that calculates these dependencies, translating raw infrastructure alerts or task associations into business impact awareness.

Mechanics of Impact Propagation

Impact calculations in ServiceNow traverse the CMDB hierarchy from downstream (infrastructure) to upstream (services). This is in contrast to discovery or service mapping, which often map top-down.

• Triggering Event: When a configuration item is added to an active task (such as an Incident, Problem, or Change Request) as the primary Affected CI (stored in the task_ci table), the impact engine is initialized.
• Relationship Traversal: The engine queries the cmdb_rel_ci table and follows relationships upward.
• Dynamic Service Population: The engine identifies all impacted Application Services, Business Services, and Service Offerings that lie upstream from the affected CI. These impacted services are inserted into the Impacted Services [task_cmdb_ci_service] table.

The "Refresh Impacted Services" Action

On task forms, users can manually trigger this calculation by clicking the Refresh Impacted Services button (or it can be automated via business rules and system properties). This utility is vital for CAB reviewers and service owners because it dynamically calculates the scope of a proposed change or incident without requiring manual lookups.

---

Impact Rules and Redundancy Modeling

By default, an outage on a child CI propagates up to its parent CIs. However, in enterprise environments, systems are engineered for high availability. To prevent false alarms, the impact engine respects clustering and load balancing configuration items:

• Standard Propagation: A simple 1-to-1 relationship (e.g., database instance Runs on server) propagates impact directly. If the server is offline, the database instance is assumed to be down, which propagates up to the application service.
• Redundancy/Cluster Propagation: If CIs are member nodes in a cluster (e.g., cmdb_ci_cluster), the impact engine evaluates the status of the cluster as a whole. Under standard cluster rules, if only one server node in a three-node cluster fails, the cluster remains operational. The impact engine dampens the propagation, preventing the upstream Application Service from being marked as impacted.
• Load Balancer Rules: Similar to clusters, load balancers distribute traffic across multiple web servers. The failure of a single web server node does not mark the service as down if other nodes remain active. The relationship class (e.g., Members of::Member) combined with specific impact rules determines the calculation.

---

Task Relationships: Affected CIs vs. Impacted Services

Understanding the database schema is essential for the CIS-DF exam. The platform maintains two distinct tables on task records to track CI relationships:

Real-World Workflow Example

1. A monitoring tool detects that virtual server SVR-PROD-09 has a failed hard drive and creates a P1 Incident.
2. The Incident's "Configuration item" field is set to SVR-PROD-09 (added to task_ci).
3. The impact engine executes (automatically or via the "Refresh Impacted Services" action).
4. The engine traces the relationships: SVR-PROD-09 hosts Tomcat-Instance-01, which supports ERP Application Service, which is consumed by Enterprise Finance Business Service.
5. ERP Application Service and Enterprise Finance Business Service are added to the task_cmdb_ci_service table.
6. The service owners for Finance are automatically notified of the degradation.

CMDB Impact Rules Configuration

Under the hood, ServiceNow uses the CMDB Impact Rules [cmdb_impact_rule] table to govern how impact propagates between specific classes.

• Impact Rules: These specify a parent class, a child class, and the propagation logic. For example, a rule can specify that a critical outage on a Database Instance propagates 100% impact to an Application Service, but an outage on a Printer does not propagate to a Subnet.
• Standard vs. Custom Rules: ServiceNow provides out-of-the-box impact rules for all common relationship types (e.g., Runs on, Depends on, Hosted on). However, administrators can create custom impact rules to handle custom CI classes or unique operational hierarchies.
• Influence and Severity: Rules define the percentage of influence a child node has on its parent. If a child node has 50% influence, a single failure might only trigger a warning state on the parent CI rather than a critical outage, enabling more granular service status reporting.

System Properties and Performance Tuning

Because relationship trees can contain thousands of CIs, traversing them recursively can be resource-intensive. Administrators configure system properties to balance impact awareness with platform performance:

• com.snc.change_request.refresh_impacted_services: Controls whether the refresh action runs automatically when the primary CI on a change request is updated.
• Traversal Limits: Properties limit the maximum depth (number of levels) and total number of CIs evaluated during a single impact calculation. If a CI has massive upstream fan-out (such as a core network switch), the calculation can be capped to prevent database locking or slow transaction times.
• Custom Impact Rules: Using the CMDB Impact Rules module, administrators can write scripts or define conditions to override default propagation logic. This is helpful when specific business units use customized relationship types or have distinct definitions of what constitutes a service-level agreement (SLA) breach.