Limits of logical name and is there a better work around?
Logical Name is the primary key field for devices. In the Out-of-the box Service Manager, it is used in all ticket type (interaction, incident, change, task, problem) to relate the ticket to the device. Our environment is different.
We have needs, on a very regular basis, to re-use the identifier of a device. For example, we are replacing a web server with a new device. The internal and external links to that device all point to the specific device. If we re-use the logical name, we have an inaccurate history for the device. If we insist on a unique logical name, there is significant extra work for us or others.
To get around this, we have a second, unique field (called term id) that users know. We hide the logical name completely. While we do not encourage re-use of the term id, we do allow it. This, of course, has its own problems. If you search for the incident history though incident management based upon a term id, you may be looking at multiple iterations of the device. If you search for the incident history from the device record it will use the logical name and produce only the current device.
Additionally, relationships are based upon logical names, not term ids. Users must now know both and when to use which one to get the best out of Service Manager.
Are there better ways to accomplish this?
Re: Limits of logical name and is there a better work around?
Thanks for your mail. This is identified as a priority item in our roadmap, so let me try to give you a perspective of what we plan to do and how to address it.
The problem you are raising and that is known in the SM community under the "logical.name" issue is now well identifed and is the single biggest priority of our next SM version. We are actively working on it and have initiated a design partnership.
In the mean time, the workarounds we have implemented are based on a naming convention that ensures uniqueness of the logical name, which I realize is not always optimal.