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.

[Mark Bodman]

That is the idea.  We are calling it "IRE for ALL" internally, so stay tuned on what that means exactly as we cover those broader, non-CI bases.

[s4scott]

It is great news to hear that IRE will be available for location data. That will be very helpful for companies like mine that have multiple organizations that manages different locations and as a result have separate location data sources.

[Jacques Clement]

Oh wow, this is really big and exciting. Honestly, I always wondered why all the good things of CMDB, CSDM and SG connectors could not apply across the board (including Integration Dashboard, IH/ETL, IRE, CMDB Health, etc.).

[CMDB Whisperer]

Hi Scott,

Great to hear that you are looking at using international standards.  That said, for the "Region" level I believe this is problematic.  From the work I have done previously along these lines, I quickly found how problematic this was, as there isn't a single agreed upon international standard for how to define regions and which countries belong in which regions, and that selecting one standard over another can be interpreted as having political or ethnic bias.  Further, in some cases the definition of a "region" has criteria that go beyond purely geographic specifications, which just adds to the complexity.  Finally, how regions are defined can also be company specific, for purposes of defining areas of responsibility for a business function, which may not be purely geographic but more organizational.  Where I ended up on this was that the ideal solution would be one which allowed a many-to-many relationship between Region and Location, with additional metadata on the relations so that, for example, you could say that a country belongs in either Central Europe by one standard or Southeastern Europe by another standard, and that the same country may be covered within Western Europe from a Sales perspective.