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

[Mathew Hillyard]

Hi @JagodaS 

1. No - you get nothing. This part of the platform hasn't changed since before CSDM 1.0
2. Use Client Scripts on change of the fields and Reference Qualifiers to filter the reference fields with CSDM related records if other fields are not empty.
   1. Set Service field to read only
   2. Set Service offering field to mandatory
   3. Create a Client Script onChange of Service offering to set the Service field (every Service Offering must have a Service in its Parent field)
   4. Create a Client Script onChange of the Configuration item field to set the Service offering if that CI is connected (via Service Instances) to only one Service Offering
   5. Override the dictionary entry for Service offering field (per-process so you have Control) to return connected Service Offerings if the Configuration item field is not empty.
   6. Override the dictionary entry for Configuration item field (per-process so you have Control) to return connected CIs if the Service offering field is not empty.
3. See answer to Q2.
4. Yes, see above and
   1. You will need scripting to traverse CSDM relationships and return corresponding values. Luckily for you I've already shared a server-side script include example. Just build a client-side Ajax Script Include with wrapper functions (called by the objects in step 2) to call the required function in the server-side Script Include: https://www.servicenow.com/community/developer-blog/csdm-script-include-to-traverse-ci-relationships...

I hope this helps!
Mat

[IanCox]

Great detail above -- Mathew's client-script/reference-qualifier build and pr8172510's point about keeping relationships accurate cover the "how" well. Let me add the piece that most directly answers your Q3 (users starting from different entry points), since that's usually where these rollouts get stuck.

Don't try to make every user navigate the hierarchy. Anchor each persona on the one field they actually know, and derive the rest server-side:

- End users logging incidents usually know the CI or the app, not the Business Service. Let them set the CI, and derive the Service Offering / Business Service from its relationships behind the scenes -- they never have to understand the model.

- Service-desk or request flows often start from the service. There, expose the Service Offering, constrain the CI list to related CIs via the reference qualifier, and leave Business Service derived.

Framed that way, the filtering only has to be truly bidirectional in the rare case, which keeps you close to your "avoid heavy customization" goal: one advanced reference qualifier per direction plus a small server-side derivation covers the 80% case without a wall of client scripts.

And to reinforce pr8172510, because it's the thing that quietly breaks all of it: the qualifiers can only return valid values if the CI -> Application Service -> Service Offering -> Business Service relationships actually exist and are current. Mid-CSDM-rollout they're usually sparse, so users hit empty or short lists and override them -- which recreates the exact bad data you're trying to prevent. Before judging whether the filtering "works," confirm Service Mapping / CSDM relationships are populated for the in-scope services; a lot of "the qualifier returns nothing" tickets are really relationship-coverage gaps, not scripting bugs.

Net: anchor per persona and derive the rest, use one dynamic reference qualifier per direction, and make sure the relationships exist first -- that gets you the data-quality win with the least customization.

(Disclosure: I run a ServiceNow consultancy focused on CMDB/CSDM -- the entry-point framing plus the relationship-coverage gotcha is where most of these get stuck.)