Location Aliases

[lyletaylor]

We need the ability to specify aliases for locations, because some key locations (such as datacenters  and some office buildings) are known by multiple names depending on which part of the organization is referring to it. We want to have a single main location record for those locations but also allow them to be found using whichever name is used by a given organization.  

I seem to recall having a conversation with someone a while back where he was telling me that the ability to add aliases (or something along those lines) was being added to things like locations and perhaps a few other core tables. I don't see that feature anywhere. Is anyone aware of such a feature existing OOB? Or if you have added such a feature, how did you go about doing it. I already have an idea of how I'd do it, but would also be interested in other ideas.

Thanks, Lyle

[Brian Dailey1]

Hi Kyle,

I believe what you are referring to is Field Normalization, which would allow you to essentially specify aliases for the "Normal" value (i.e., official name) of the location.   For that, please see here and read through the wiki book:   http://wiki.servicenow.com/index.php?title=Field_Normalization#gsc.tab=0

Another, less complex, option might just be to just add the accepted official location as the Parent to the other locations for that room/building/etc., and then just lookup and use that value instead whenever one of the child locations gets selected.   If you wanted to explore this option, I could help you to flesh it out.

Good luck,

-Brian

[lyletaylor]

Thanks, Brian. It's possible that field normalization is what this person was telling me about. However, it does not work for reference fields, so I don't think that is an option we can use here. I also considered making the other names be sublocations of the main location as well, and that could work but ends up being less clean for the user, especially if we have other valid sublocations for that location.

Right now I am considering doing something a bit similar to that that I also did for CI aliases. In a nutshell, I would extend the location table to create a Location Alias table. Then I add a field named "Alias for" to the extended table and then add that table as a related list to the location table. Then we can add as many aliases as we want to a location. I then add a client script and business rule that switches out any selected alias for the real location. So, that's similar to what you proposed, but ends up being a little cleaner in terms of user experience.

[Brian Dailey1]

Hi Lyle,

Or you could try secret option (C)... add another self-referencing field (similar to parent) on the Locations table and use this to identify the aliases for a main/official   location.   This way, you wouldn't lose the parent hierarchy needed for your actual valid sublocations.

e.g.,

• Add a self-referencing field 'u_alias' to the location table and use this to track your aliases (by selecting the "Official" location in this field on any a.k.a. location record)
  • You will then get a related list of all aliases for the official record of that location.
• Use the 'parent' field to maintain your actual hierarchy of Location/Sublocations, etc.

-Brian

[lyletaylor]

Hi Brian,

Yes, that would work as well. I guess I would just need to consider whether it is better to store the aliases in a separate table or simply keep them in the base table. There are probably small pros and cons either way. It may not make much of a difference in this case.

Thanks for the input.

-Lyle