Michael, Actually I think there is at least one good reason for why ARS supports (or maybe "supported" is a better phrase) this feature.
The idea is a "group alias". ( Two "Group" form entries with the same 'Group ID' value but different 'Group Name' values.) This is a designed feature from the "old days". Ref: v4.0 admin_vol1.pdf pg 1-26: This is part of a table "Table 1-3 Key Fields in Group Form": " Group ID Integer ID that is the recognized identity of the group. For groups that you create, the ID should be greater than 10. If you use the same ID with multiple group names, you must keep the Group type the same for each because you are creating aliases for the same group. " and a parallel v6.3 doc segment has this to say: BasicGuide-63.pdf page 114 " If you use the same ID with multiple group names, you must keep the Group type the same for each because you are creating aliases for the same group. To make sure that you do not create duplicate Group IDs, use Remedy Administrator to build a unique index on the Group ID field in the Group form. (For more information, see "Defining indexes" on page 210.) " However at the lowest level these values are used for one of two reasons: Access Controls or Notifications. And the point of the alias has to do with the latter use not the former. Over time it is possible (and likely) for your groups to be organizationally merged. For example: "Helpdesk HR"(10000) and "Helpdesk Technical"(10005) might become "Service Desk"(10005). In the case of Notification actions in workflow these values are held as strings('Group Name', 'Login Name', hard coded "Email Addresses" or lists of combinations of those things) in the object definitions. So when groups merge into a new name (or into one existing name) you need to maintain that 'Group Name' that still has notifications going to it, or pick through your entire application and replace the old value(s) with the new value(s). The alias values allow you to solve this "normal change" with a data change in one ARS form. ( You can change the group ID values to now be Helpdesk HR"(10005) and "Helpdesk Technical"(10005).) This would allow you to not have to change your application and notification actions sent to "Helpdesk HR" would now be routed to the 10005 'Group List' members instead. (Yes you likely need to move all users in 10000 into 10005 in the 'Group List' too. So that 10000 can be total abandoned.) Keep in mind that if the 'Group ID' is used as an Access Control then those references are NOT removed by changing data in the Group form. So if you ever reuse that value later(10000) then those places that this Access Control is used will still be there and will "spring back into life" as soon as that group is defined again in the Group Form. Also if your application allows your users to type (manually) in a value then that muscle memory of entering "Helpdesk HR" will also not go away anytime soon. So you may want to support users still using that value (for a period of time) to again, not break your existing processes during changes like this. ( The "group alias" feature allows for this.) So... I think the point was to allow an easier transition under normal and expected business org changes. However, there may be other good reasons too. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On Jan 9, 2008 4:10 PM, Durrant, Michael M. - ITSD <[EMAIL PROTECTED]> wrote: > ** > > I did an application export/import from development to production and it > replicated our existing Group IDs. Why is there no unique index on Group > ID? I can't fathom a situation where I would want differently named groups > with the same ID. Am I totally off-base on this or ??? > > Thanks, > > Michael _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"