Tag a CI to multiple locations via customization

[K14an]

Hi folks,

I have come across a sort of wierd ask from one of my stakeholders related to storing the data in CMDB.

Currently, we have majority of CIs following the below naming convention and associated with respective locations

<AppName> + <Location A> + <Environment>    tagged to    <Location A>

A new vertical wants us to allow storing the apps in below format:

<AppName>   tagged to    <Location A>,  <Location B>,  <Location C>

This would mean changing the location field type to "List". I want to deny this option but need more backing. Can someone please help me with some justifications why this is not a recommended practice?

[SteveMacWWT]

The logical entry for an app is in the Business Applications table. The App Services are where you track all the instances, so if you are talking multiple instances, like @AJ-TechTrek said, this is not best practice. In fact I would put this in the 'Really bad practice' category. Many companies have run into issues using the Bus App / App Svcs tables incorrectly over the years and that causes issues as you try to use additional portions of the toolset. 

One solution might be to show the 'Business Application' field on the form (this is an OOtB field on the Task table), and use a BR to do the lookup from App Svc and populate the Bus App field.

Although Business Applications are not meant to be an operational CI, this is a common practice to make reporting easier.