CSDM and WSD

[Marc De Mol]

We bought and installed WSD, probably one of the first companies doing so, a while ago. The new location hierarchy mentioned in the Draft CSDM 4 is not aligned with the classes coming in when installing the WSD plugin, WSD classes are extending the cmn_location table but when already having the hierarchy there, it doesn't take it over, there is no keeping track of the hierarchy in cmn_location when using the WSD forms and vice versa.

@scott_lemm 

Is there a roadmap to get those new tables in the CSDM side and start making use of them or at least making sure they keep in line on the hierarchy?

Making them always available like you do for other plugin tables.

We also had some impact on the Asset side with WSD and had to keep the Asset locations in the cmn_location to be able to reference them on the rooms. I presented this to ServiceNow succession architects and now I see the extention of the cmn_location table attributes:

• Location Type – where does this location record fit into the hierarchy (treepicker) of locations?
These choices provide the ability to create a hierarchy of location data allowing you to scale the
choices to fit your organizational needs.

• Region
• Country
• State/Province
• City
• Site
• Building/Structure
• Floor
• Room (This more correct then on WSD! nice!)

While WSD:

• Region – e.g., Americas 
• Site – e.g., North America
• Campus – e.g., California
• Building – e.g., CAL-B1
• Floor – e.g., CAL-B1-F1
• Area – e.g. Financial department (Optional)
• Space/Room – e.g., CAL-B1-F1-SP1 

 Thanks for considering.

[scott_lemm]

Hello @Marc De Mol ,

Thank you for this question. We (CSDM) are working with WSD to utilize the CSDM standards in an effective manner.

The CSDM standards are available for all customers regardless of ServiceNow Product licensing. That said, the Location material developed as a CSDM standard will be the default for everyone. WSD will enhance their solution to align with CSDM. Additionally, we are looking at providing the first 4 layers of the Location Type stack using International Standards thus providing data to load/populate Region -> Country -> State/Province -> City. Beyond the first 4 layers will be customer configured values.

We expect to have examples in the new year.

Hope this helped.

Thank you,

Scott Lemm

[Marc De Mol]

Oh nice, was improving the post while already answered!

So if I understand correctly, the cmn_location "Parent" model remains the future model and WSD will align on the use. As we kept the parent updated in line with the added class field, we should be fine. Excellent news on the global standard usage?

The address fields on the location records, anything foreseen to align these on the hierarchy? Make these inherited from the parent hierarchy?

A building (or any of it's child records) in Paris for instance could have the Region, Country, State/Province and City populated from the parents.

Thanks for the swift reply, much appreciated!

[scott_lemm]

Thank you @Marc De Mol 

There are several opportunities to provided more effective value including auto-populating records based on parent references. Also, look in 2023 for the expansion of IRE to manage data imports beyond CMDB to include Location.

"Work smarter not harder" is the mantra I share with our internal teams 🙂 

[CMDB Whisperer]

That's really exciting to hear!  Do you know if this will be accompanied by the ability to use IntegrationHub-ETL beyond CMDB as well?