Location management

[Droid101]

So I have an interesting dilemma... basically, our company needs a solution to be able to track all of our locations. It will need the following information:

Company Name
Location (address, phone, etc)
Sub locations (different locations of the same company)
Sub location number, address, phone.
Each sub location's President, Manager, IT contact, etc.
Business hours
After hours contact number
Applications used

So, it will need to be a tree of sorts, because many of our locations are sub-companies. Some of our locations are merely subdivisions of our main company. And it needs to be easily accessible to our support staff to be able to look up information.

The "Locations" module doesn't really fit this need, as "sub" locations don't really exist in there as I see it.

Anyone have a good method to do this (or even a different product used)? Any tips would be greatly appreciated.

[Mark Stanger]

The location table just uses a regular parent-child relationship to define location, sub-location, sub-sub-location, and so on. Just use the 'Parent' field on the location form to define the hierarchy.

[nikita_mironov]

We are using the following hierarchy in Locations:
Company>Region>Country>City (We have one company)
We have separate CMDB CI Class to store office information such as exact address (WAN Site) and it has City as its parent as we manage office connections to WAN and Telephony services.

With your "multi-company" approach within one SNOW instance I would keep physical geography in Locations using hierarchy:
Region > Country > City (this thing changes rarely)
and invent Company object to store Company information with subsidiaries Parent-Child references (this may change more frequently).

Of course with this approach your User records and possibly CIs should get both reference attributes populated: Location (Leaf-level, City) and Company (Leaf Level) giving the ground on independent or joint reporting over physical geography and company(s) structure.