Best approach to populating the Location table for multi-state health system

[Blue]

Has anyone come up with a good approach to populating the Location table to support IT Service Management functions like INCs, CHG, RITM, etc.?

How have you structured your location table, does it have a hierarchy?

Thanks

[Manville]

Location data is some of the most important data in ServiceNow. I think its only behind users and groups.

• Use the parent hierarchy. the location navigator allowing drill downs is very helpful. State -> city -> campus -> building
• Buildings and campuses should have addresses. floors and rooms should inherit addresses those addresses.
• Maintaining rooms is a PAIN, but a good floor plan can be extremely useful to have attached to the floor.
• Use location type, it can be very helpful filter criteria
  • Rooms should have Location types, track the important ones: server room, OR, conference room, office space
  • Buildings should probably also have location types:  Hospital, Lab, etc.
• I like to use the Company reference to track subsidiaries's locations
• There is a lifecycle stage in locations, I haven't had a use for it yet.

Get your location data and the maintenance of it in a very solid place. It has SOOOO many tie-ins: ITSM, FSM (and CDM), ITAM/HAM/EAM, HRSD, CSM (and HCLS), Workplace Service Delivery, Health and Safety, OTM, SPO, SLO, etc.

ok serious question why is the word "C L I N I C" not allowed in the HEALTHCARE special interest group?

[Blue]

@Manville , this is great feedback. A couple questions. I get the parent child hierarchy for what you describe. I can get us down to the building and campus. How do you build a location entry for floors/rooms?

So you input the address on the location entry for the building? I assume for a campus with multiple buildings with addresses that are unique you are not tracking the address at the campus level?

What about Suites?

Are floors a line item with no address and just a floor number for the name? what kind of detail is entered with a floor?

[Manville · Accepted solution]

I like addresses at BOTH the building and campus level. or to indicate a primary building on a campus. You could do away with the primary building and address at campus level, but I like providing an intelligent default for someone just sending something to a campus. If the campus is really just not centralized to that point, then leave the location at the building level.

A floor is just a location with a location type of floor and a parent that is a building. A room has a parent of a floor. Suites could be an in between for floor and rooms.

I find a more granular typing to indicate purpose to a room to be very helpful: conference room, office, printer room, OR, ER, exam room, etc. This can help make you to align priority to particular rooms. fixing a device in an OR room is more important than fixing a device in a office space.

I like to name floors by combining the building name with the floor number. Floors can seem like a placeholder, but I find that floorplans can be very reliable so I like to attach them there. you can later do some fun things with floor plans: https://www.youtube.com/watch?v=wiebJJvP-Yw

keep in mind, you can also track other locations, like vendor locations and associate them with their companies. An interesting use case when you get into field ops or asset management. Not very important for ITSM though.

To create a floor or room, add the location type to your form, set the name and parent, and save. Full name field is the display label for the record. Usually this is done programmatically.

[Jennifer Red]

Did you all have an issue with rooms being the same name at different locations? This has come up for us after we have done the hierarchy. We're getting flagged on our platform health for locations with the same names. Any help/advice would be appreciated.