Idea ID: 1648764

Need a "Full Name Solution" for operators and contacts

Status : Declined
over 3 years ago

In majority of customer's environments the unique ID (Login Name) for users is a 4 letter OPID (Operator ID) or combination of letters and numbers that most people don't know what it is/means.

This makes it difficult to identify who is the contact or service recipient in a record. This is not only about the activities, so the option to use full name in the environment settings in some modules is not enough.

This is a request to get a solution similar to the "Logical Name Solution" for UCMDB in SM9.

So what user wants is all references to people to be shown by their Full Name.
While their Login Name is used in the background to handle all references.

Additional information: In most of the companies the contact.name or also the callback contact name is also a code, so in difference to an OOB system, what users see does not tell them who the user is. The reason to use a code is that several people have the same name, so then they use something that is unique, like an employee number or any other code

This is related to QCCR1E138089

Tags:

Labels:

SMA-SM
  • We allow PS/partner to expand OOB logical name solution to other tables, and there is no plan to support "Full Name Solution" for operators and contacts in SM OOB.
  • Why can we use the same solution that is use for the CI name using the datadict configuration ?   We tried it and it seems to work fine.  Unfortunatly support told us that is not a supported configuration.  We don't understand why.

    This seems an acceptable and viable solution. Can you please consider support such configuration.

     

    Thank you

     

  • We would need this as well. It also needs to be considered that name (operator table) and contact.name (contacts.table) are not necessarily the same.

    name field in operator table --> refers to a user in Active Directory
    contact.name field in contacts table --> refers to a unique "person" (either employee in the company or a customer)

    Since a "person" (employee) could have multiple  user accounts in Active Directory (normal login, admin login, technical user account, etc..) there 

    is no 1:1 relation between user name (operator table) and contact.name in contacts table.