Ensuring Approved Relationships Within CMDB
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hello,
Within the CMDB we want to ensure that all relationships between CIs are consistent. That is each class of CIs has a list of approved relationship types and we want a system that tracks if any do not follow the approved types or are in the incorrect direction (upstream/downstream). What are best practices for this?
Thank you,
Adam
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @adamtoth ,
The most native way to handle this is through Suggested Relationships in the CI Class Manager.
Navigate to CI Class Manager - your CI class - Suggested Relationships and define the
relationship types that are valid for that class. This tells the system and users what
relationships are considered appropriate. The relationship editor then surfaces only those
suggested types when someone tries to manually link CIs, which cuts down on random or incorrect
relationships being created.
Now, Suggested Relationships alone don't enforce , they acts as a guide. To actually detect relationships
that fall outside what you've defined as approved, the CMDB Health Dashboard → Relationship
Correctness check is your friend. It flags any relationships that don't match your Suggested
Relationships config, and from there you can kick off Remediation tasks to clean them up. That's
the intended OOB flow for this.
Where Staleness Rules come into play is slightly different , they're about the health of the CIs
involved in a relationship rather than whether the relationship type itself is approved. A
relationship gets flagged as stale when one of the CIs on either end hasn't been
updated/rediscovered within your defined threshold (e.g. 60 or 90 days). You configure those
thresholds in CI Class Manager -> Health → Correctness → Data Refresh Rules. So if you're seeing
stale relationships in the health dashboard, it usually means the underlying CIs are no longer
being discovered — not necessarily that the relationship type is wrong.
If you want hard enforcement — actually blocking unauthorized relationship types from being
created , there isn't a clean OOB toggle for that. The typical approach is a Before Business Rule
on cmdb_rel_ci that checks whether the combination of parent class, child class, and relationship
type exists in the cmdb_rel_type_suggest table, and throws an error if it doesn't. Just be aware
that Business Rules on cmdb_rel_ci won't fire when Discovery or IRE creates relationships , those
bypass standard BRs for performance reasons (KB0694512). So you'd mainly be catching manually
created ones.
Hope this Helps
If it helped you please do mark it as helpful and accept the solution
Thanks,
Vishnu
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi Vishnu,
Thank you very much for the reply. Is the relationship correctness check in the relationship health dashboard? Will turning it on affect platform performance?
Thank you,
Adam
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi Adam,
Yes, the Relationship Correctness check is part of the CMDB Health dashboard - you'll find it
under Configuration > CMDB Health. It sits alongside the other correctness checks like Staleness
and Duplicates in the same dashboard view.
As for performance, turning it on does kick off a scheduled job that evaluates relationships
against your Suggested Relationships config, so there is some overhead involved. That said,
in most instances it's not something you'd notice in day-to-day platform performance as long
as you're running it during off-peak hours, which is the default behavior. The impact really
depends on the volume of CIs and relationships you have in scope - if you're talking tens of
thousands of CIs with dense relationship maps, just make sure the job schedule is set to run
overnight or during a maintenance window rather than during business hours.
Hope that helps,
If it helped you please mark it as helpful and accept the solution
Regards,
Vishnu