Service Impact Calculation in SNOW 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!

[abbasshaik4]

Hello @vgkorat,

Please refer to the link below:
Add CMDB tables or classes for impact calculation • Australia IT Operations Management • Docs | Serv...

If it is helpful, please mark it as helpful and accept the correct solution by referring to this solution in the future it will be helpful to them.

Thanks & Regards,

Abbas Shaik

[vgkorat]

hi @abbasshaik4  ... Thanks for the link.. But 

Statement: CFS/RFS Impact Calculation Limitation

In our CMDB, CFS (Customer Facing Service) is mapped to the Business Service class (cmdb_ci_service_business), and RFS (Resource Facing Service) is mapped to the Technical Service class (cmdb_ci_service_technical).

However, both cmdb_ci_service_business and cmdb_ci_service_technical are not part of the classes supported by Impact Calculation.

We also attempted to work around this by adding cmdb_ci_service_business and cmdb_ci_service_technical to the em_impact_inclusion_list, but these classes cannot be added to the inclusion list, as the list does not support them. This means there is no way to bring these classes into scope for the standard Impact Calculation engine.

As a result, the proposed solution of relying on out-of-the-box Impact Calculation does not work for our CFS/RFS model, since:

The classes involved (Business Service, Technical Service) are excluded from Impact Calculation by design.
The inclusion list cannot be used to force these classes into scope.
Without either path available, impact does not propagate from Resource → RFS (Technical Service) → CFS (Business Service) through the standard engine.
We need an alternative approach to achieve impact calculation for these two classes, since the standard Impact Calculation mechanism is not viable in our scenario.