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

JagodaS · 4 weeks ago

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

Is there any out-of-the-box capability in ServiceNow to support this kind of dependent filtering between:
- CI
- Service Offering
- Business Service
If not, what is the recommended approach aligned with CSDM?
- reference qualifiers?
- dynamic filters?
- client scripts / UI policies?
How do you handle cases where users start from different entry points (CI vs Service)?
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 · 4 weeks ago

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.

View solution in original post

Mathew Hillyard · Friday

Yes, it goes without saying that if the services haven't been fully populated then the resulting data will be poor. This is why staged implementations that touch desks/end users can be fraught with problems - CSDM is one area where I usually advise a one and done go live in that space because dual running has so many issues and ends up with bad data.

In my experience unless it's their personal device end users will almost never know which CI caused the Incident , and they're also almost never going to fill out a Change, Incident, Problem or Service Request. I wouldn't even bother offering up any of CSDM fields to end users - automation or AI can ascertain the most appropriate Service offering contextually from what they enter as the issue. For Catalog Items the offering should already be populated on the related list.

For agents, with Incidents they rarely know the CI at creation so it shouldn't be mandatory or the starting point when creating an Incident as it is intended to be the causal CI. Of course, you definitely want the Configuration item filled in at resolution! Nowadays the vast majority of all types of ITSM record are no longer created by people anyway so such records should normally be automatically configured to populate all 3 CSDM fields.

It's precisely that the forms (which are usually chock full of fields, UI policies etc already) and the scripting can get messy that I recommend customers focus on just two fields - Run with Service offering as the focus, which will always take care of the Service, and Configuration item, with the goal that all resolved ITSM records are populated with all 3 fields at resolution. This can require a bit of unlearning old habits and a strong tie to setting up the Portfolios right from the beginning, but its an approach I've not had issues with so far.