CSDM Implementation

[MirzaSaquiB]

Hi Experts,

I am working on the CSDM Crawl phase. whatever was the table migration is completed.

Relationship between Business Application and Application Service and Application Service and Service Offering is also completed.
I have created the client script to populate the business service whenever the Service offering is selected. but Instead of the related record all the records are coming in the cmdb_ci field. I used the reference qualifier on cmdb_ci field, but it also fails.

Provide me the specific solution for this.

Thanks

Mirza

[21121A3359]

Hi @MirzaSaquiB ,

This usually happens because the cmdb_ci field is not getting properly filtered based on the selected Service Offering or Business Service context.

A better approach is to use an Advanced Reference Qualifier instead of only a client script. In many CSDM implementations, the relationship flow is:

Business Application → Application Service → Service Offering

So the cmdb_ci field should ideally filter only the related Application Services or CIs associated with the selected Service Offering.

You can try this approach on the cmdb_ci reference qualifier:

javascript: 'sys_idIN' + new global.ArrayUtil().convertArray(
new CIUtils().getCIsForService(current.service_offering)
).join(',')

Or create a Script Include that returns only the related CIs mapped to the selected Service Offering and call it from the reference qualifier.

Also verify:

• The relationships are correctly stored in cmdb_rel_ci
• The Service Offering is linked to the correct Application Service
• The reference qualifier is set as Advanced
• Client script is not overriding the qualifier after load/change

If the qualifier still shows all records, check whether:

• Dictionary override exists on cmdb_ci
• The field uses dynamic filters from another configuration
• current.service_offering is actually populated at runtime

Using a GlideAjax + Script Include combination generally gives better control and performance for CSDM-based filtering scenarios.

[Mathew Hillyard]

Hi @MirzaSaquiB 

ServiceNow does not provide either scripts or product advice on how to populate forms.

The closest I've seen is this: https://www.servicenow.com/community/itsm-articles/how-to-configure-incident-management-to-align-wit...

You need to consider your organisation/customer. Some customers want everyone funnelled to a single field; others want to align to the CSDM model more closely.

I recommend the following:

1. Service field should only store Business or Technology Management Services.
2. Every Service Offering must have a Parent Business or Technology Management Service, so make this field read-only. This step is often missed.
3. Service offering should be mandatory. Use an onChange client script to auto-populate the Service field based on Service offering > Parent.
4. Configuration item field should be optional on creation but should be mandatory when resolving an Incident. On a Change request it should be mandatory on creation.
5. As @21121A3359 has mentioned, use an advanced reference qualifier to filter the Configuration item field. Note that there is no code provided by ServiceNow to traverse CSDM relationships. I have provided a sample server-side script include and advice on creating a GlideAjax script include client-side that you can use in a reference qualifier here: https://www.servicenow.com/community/developer-blog/csdm-script-include-to-traverse-ci-relationships...
6. Be careful with large Dynamic CI Groups - a sys_idIN query is inherently inefficient on a large table, so a Service offering connected to a DCG (or multiple DCGs) with ten thousand CIs may take a long time to render when clicking the magnifying glass on the CI field.
7. Don't bother with an onChange Client Script on Service offering trying to set a Configuration item - if properly configured, at a minimum, every Service Offering should be linked to at least 2 CIs - an Application Service and at least one CI, or a Dynamic CI Group containing at least one CI.

I hope this helps!
Mat