CSDM – How to handle CI vs Service vs Offering selection when users don’t know the full hierarchy?

[JagodaS]

Hi all,

We’re currently implementing CSDM and ran into a usability challenge when users need to select values on records (e.g. incidents, changes).

In theory, the process assumes users know the Business Service → Service Offering → CI structure.
However, in practice this is not always the case:

• sometimes users only know the CI
• sometimes they only know the service / offering
• they often don’t understand the full hierarchy

This creates a risk of incorrect or inconsistent selection across fields.

What we are trying to achieve

We would like to guide users by showing only valid, related values, for example:

• if a CI is selected → show only related Service Offerings / Services
• if a Service or Offering is selected → show only related CIs
• ideally this works both directions (bidirectional filtering)

 

Questions

1. Is there any out-of-the-box capability in ServiceNow to support this kind of dependent filtering between:

   • CI
   • Service Offering
   • Business Service

2. If not, what is the recommended approach aligned with CSDM?

   • reference qualifiers?
   • dynamic filters?
   • client scripts / UI policies?

3. How do you handle cases where users start from different entry points (CI vs Service)?

4. Are there any best practices or pitfalls to avoid when implementing this?

Context

We want to:

• improve data quality
• reduce incorrect relationships being selected
• keep the solution scalable and compliant with CSDM best practices (avoid heavy customization)

[pr8172510]

Hi @JagodaS,

For this scenario, Reference Qualifiers are the recommended approach to filter related reference fields based on existing CMDB/CSDM relationships.

• Use Advanced/Dynamic Reference Qualifiers to return only valid related CIs, Service Offerings, or Business Services.

• Use Client Scripts only when additional dynamic behavior is required (for example, refreshing dependent reference fields after a selection changes).

• UI Policies are intended for field behavior (visible, mandatory, read-only), not for filtering reference choices.

• Dynamic Filters are primarily intended for lists and reports rather than dependent reference field filtering.

The key best practice is to maintain accurate relationships between Business Services, Service Offerings, and CIs so that the reference qualifiers return valid values. Avoid hard-coded mappings or duplicated relationship logic, as these become difficult to maintain.

This approach helps improve data quality while keeping the implementation scalable and minimizing customization.

[Tanushree Maiti]

Hi @JagodaS 

Check this Get well Book: KB0831511 Business Service Offerings with Application Service Relationship 

 Attached is CSDM 5.0 architechture which will help you to understand the mapping better.

Also check: 

https://www.servicenow.com/community/developer-forum/populate-service-offering-based-on-configuratio...

https://www.servicenow.com/community/cmdb-forum/cmdb-ci-vs-service-and-service-offering/td-p/3387114