impacts::impacted by relationship type - How and why are you using it?

[Bobby Campbell]

How are you using this relationship type? Is it considered CSDM-compliant, or should we consider unwinding it? 

We are in the early phase of aligning to CSDM and have about 1600 relationships set as Impacts::Impacted By, mostly involving Servers, Database Instances, and Business Apps.  I've been unable to locate documentation on this in the CSDM 5 white paper, OOB Suggested Relationships table, Docs, Community, etc.

[AJ-TechTrek · Accepted solution]

Hi @Bobby Campbell ,

As per my understanding, That will help you.

“Impacts::Impacted by” is not CSDM-compliant. It’s better to unwind it over time and replace it with recommended relationship types aligned to CSDM, which improves data quality, reporting, and downstream integrations.

1) Is it considered CSDM-compliant?
* Short answer: No — “Impacts::Impacted by” is not part of the out-of-the-box (OOB) recommended CSDM relationship set.
* In CSDM 5.0 (and prior), ServiceNow provides a “Suggested Relationships” table and reference diagrams, which mostly focus on relationships like:
* Depends on / Used by
* Runs on / Hosted on
* Consumes / Provides
* Composition / Aggregation
* “Impacts::Impacted by” isn’t listed as a recommended CSDM-compliant relationship because it’s quite generic, and doesn't express clear service or technical dependency, which is what CSDM aims to standardize.

2) Why do people use it then?

* Some teams create these generic “Impacts” relationships historically to loosely show that CI A somehow affects CI B (e.g., a database instance impacts an app).
* It can help visualization in the Dependency Views but becomes messy and non-standard when trying to report, measure service health, or automate impact calculation.

3) Should we unwind it?

* Recommended: Gradually refactor away from generic “Impacts” to specific, CSDM-aligned relationships.
* For example:
* Instead of: App → Impacts → DB instance
* Use: App → Depends on → DB instance
* This gives clearer, actionable dependency data that works well with ServiceNow tools (Event Management, Service Mapping, CMDB Query Builder, etc.).

4) Practical approach / next steps:


A. Audit your 1600 relationships:

* Which objects are linked (apps, DBs, servers)?
* Do they map naturally to standard CSDM patterns like:
* Business Application → Depends on → Application Service / Technical Service
* Application Service → Runs on → Server
* Application Service → Depends on → Database
* If yes, plan to convert them.
B. Use CMDB Health / Data Manager / Relationship Editor to bulk correct.
C. Document new modeling standards for your team.

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025

[Bobby Campbell]

Thank you, AJ!  This is exactly the type of guidance that helps my overall understanding of CSDM. Really appreciate the thoughtful response.