I am unaware of any method to associate an incident to multiple contacts. All of the language written in the support documentation refers to a single instance of an associated contact...which makes sense since the automated notifications are set up for a single user.

you are looking at more help desk customization. By adding another drop down you could accomplish this and then reference it within all of your notifications!
-jgo

But if you did that....how much would it add to the complexity of your system? For example, when your Acknowledge Contact rule fires and sends an updating message to the "Contact"? These kinds of customizations would also have to be considering during upgrades. Sometimes keeping it simple can make for less work...now and down the road.

It would be interesting to ask Symantec if the next version of the Help Desk product (Service Desk) would include this functionality.

I agree with keeping things simple and maintaining supportability.

But sometimes a simple customization can add massive amounts of value. In the help desk manual there is a section on "tailoring" your help desk to meet your needs. I would strongly suggest that if you want to add a field do so in a test environment first following the manual and go from there.

.02 cents
-Jgo

The first steps would be to define why you have several contacts for a single incident?
Then when this is describe you might have other solution which will come up as for us we have defines a "Main Contact" which is unique and then if anybody else should be considered as contact we created a Group and assign them as "Owner".

just some idea...

Thanks for the response. There are several reasons - eg, a VIP may want an admin or underling to manage the issue but also wants to be notified on progress and change of status. Or, the contact may be a manager requesting service for an employee who should also get updates. Most of these requests are ad-hoc and generally difficult/impossible to pre-define with groups or notification rules.

We can't use the owner field, as that is reserved for the resolving group to insure group/queue visibilty of all issues.

In these cases, we just create Notification rules to include the additional contacts in any updates/changes to the request.  You could create custom notifications for specific groups of users or types of requests.  For example:  If that VIP submits the requests, you could have a Notification rule that sends all up updates/etc. for requests submitted by that VIP to the Contact (the VIP) and to additional users, in this case the admin or underling.

This will not allow the additional users to opena nd view the incident direclty from the WinUser or Guest consoles.  It will only include them in update e-mails, etc.  If you want the additional contact to see the request in their user console, they will have to be set as the Contact.  If you want them to open requests of which they are not the contact, they will have have to "View Incident" previleges in the Helpdesk console (possibly even be Workers).