Impacted Service Calculation using CMDB

[vgkorat]

Hi all,
We're working on an Event/Alert Management use case where we need to automatically compute impacted services whenever an alert is raised on a Resource (CI), but our instance does not have Discovery or Service Mapping installed.
Our CI hierarchy:
CFS (cmdb_ci_service_business)
└── RFS (cmdb_ci_service_technical)
└── Resource (cmdb_ci_hardware)

CFS → cmdb_ci_service_business
RFS → cmdb_ci_service_technical
Resource → cmdb_ci_hardware

These CIs are related manually today (no auto-discovered relationships/dependency maps).
What we're trying to achieve:
When an alert fires on a cmdb_ci_hardware record, we want the platform to traverse the relationships upward (Resource → RFS → CFS) and populate the Impacted Services (both technical and business) on the Alert/Event, similar to what out-of-box Impact Calculator does when Service Mapping is present.
Questions :

Since we don't have Discovery/Service Mapping, is it possible to still use the standard CMDB Impact Calculator / BSM Map / Impact Rules (cmdb_rel_type based) purely on manually created relationships, or is Discovery a hard prerequisite for impact propagation?
If manual relationships are sufficient, what relationship types (e.g., "Depends on::Used by", "Runs on::Runs") should we use between Resource→RFS and RFS→CFS to ensure impact propagates correctly in the CI relationship direction ServiceNow expects?
Do we need to configure anything specific under CI Relations → Impact Rules or cmdb_rel_ci_impact_rules for this custom hierarchy (Business Service → Technical Service → Hardware) to work with impact calculation?
Is there an out-of-box way for Event Management/Alert Management to auto-populate the "Affected CIs"/"Impacted Services" related list on the Alert using just these manual relationships, or do we need custom Business Rules/Script Includes to walk the relationship tree ourselves?
Are there any known limitations when using cmdb_ci_service_business and cmdb_ci_service_technical together in impact calculation without Service Mapping's automatically discovered dependency views?

Any guidance, documentation links, or shared experiences on setting this up correctly (without Discovery) would be really helpful.
Thanks in advance!

[Vikram Reddy]

Hi @vgkorat,

Discovery isn't a hard prerequisite for CI Relations Formatter or BSM Map, that traversal walks cmdb_rel_ci whether the relationships are manual or discovered. The real gap is on the automation side: the engine that auto-populates Impacted Services (svc_ci_assoc) is built for Application Services fed by Service Mapping, not a generic Business Service/Technical Service hierarchy, so nothing OOB walks Resource > RFS > CFS and populates the alert automatically.

• Relationship type: use Depends on::Used by between Resource and RFS, and RFS and CFS, it's the standard OOB descriptor pair for this dependency direction
• Impact Rules: I found no documented cmdb_rel_ci_impact_rules module for this, don't spend time chasing it
• Automation: write a Business Rule (or Script Include) on em_alert insert that does a GlideRecord traversal of cmdb_rel_ci upward from the alert's CI and populates Affected CIs/Impacted Services yourself, since Event/Alert Management has no native relationship-walking feature for this without Service Mapping

If this unblocks you, please mark it accepted.

Thank you,
Vikram Karety
Octigo Solutions INC

[IanCox]

 

@vgkorat — you're essentially rebuilding impact propagation by hand, and the good news is @Vikram Reddy has the mechanics right: the CI Relations traversal and BSM Map walk cmdb_rel_ci whether the relationships were discovered or entered manually, so Discovery/Service Mapping isn't a hard prerequisite for the traversal itself. Depends on::Used by for Resource→RFS and RFS→CFS, plus a Business Rule/Script Include on em_alert insert to walk upward and populate impacted services, will work for this hierarchy.

The thing I'd flag before you commit to it: a hand-maintained relationship layer is a maintenance liability, and it's exactly what generates orphaned and stale CIs over time. Every new host, every decommission, every app move has to be re-related by a person — and the day someone forgets, that Resource silently stops rolling up to its RFS/CFS. The alert fires with no impacted service and you don't find out until it matters. Manual relationships don't fail loudly; they just quietly go orphan.

So the split I'd suggest: build the Business Rule traversal now to unblock the alert use case, but treat it as a bridge, not the destination. If impact analysis is going to be load-bearing for Event Management, top-down Service Mapping on the services that actually matter is what keeps that relationship layer current without a human babysitting it. You don't have to map everything — just the technical services feeding your priority alerts. Do that and your custom traversal becomes a fallback rather than the whole engine.

Either way, put an orphan/relationship check on a cadence (CMDB Health orphan rules, or a scheduled report on CIs in this hierarchy with no upstream rel) so drift surfaces before an alert does.

(Disclosure: I run a ServiceNow consultancy focused on CMDB/CSDM and Service Mapping — no pitch, happy to go deeper on the traversal or the mapping trade-off.)