Tarun, I agree with Rabi - it could take some time to implement. Here is how I implemented it here:
I had a need to determine ahead of time which group or technician would be auto-assigned a new ticket before submitting it... For two reasons: On a new ticket before the technician submits it, the group or name the ticket will be assigned is displayed. This allows the technician to know ahead of time if this new ticket will be assigned to a group that they do not have access to. The second reason is for my benefit. When I first started at this company I needed a method to quickly troubleshoot the auto-assignment process. After creating a number of test tickets just to see who got auto-assigned I decided to create a SQL function that would show me what I wanted without creating tickets. To get the auto-assignment I now simply make one Set Fields SQL call to the function. The function returns either "G:GroupName" or "I:IndividualLoginName". The next workflow object (AL or Filter) then extracts either the group name or the technician login name. Since the auto-assignment process is the same as out OOB (HelpDesk 5.5) I only use this on the client side (Active Links). If we ever needed to add an additional parameter to help determine the auto-assignee all I would need to do is update the SQL function and pass into the function (Set Fields SQL) the additional criterion. I would then add two filters and attach to each form that has tickets (eg. HPD:HelpDesk, CHG:Change, CHG:Task) which call the function and sets the assigned to group and possibly the assigned to login. These two filters would fire before any of the [200 or so] auto-assignment filters. With this approach I would not have to modify the OOB auto-assignment filters. When the auto-assignment filters run they would detect that the new ticket already has been assigned and therefore would never actually do anything. If you want to go this route then I would start by creating a SQL function that exactly duplicates the existing functionality. After you have thoroughly tested this function then look at adding additional parameters. One caveat: If you are planning to move to ITSM 7.0 soon you may want to first look at how the auto-assignment process works. It could be very different. HTH Stephen -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rabi Tripathi Sent: Friday, May 12, 2006 9:42 AM To: [email protected] Subject: Re: Possibility of additional parameters with Skills in addition to CTI and RSD Tarun: Yes you can, as is always the case with ARS applications (assuming ITSM here). But I am not sure you really want to. First you will need to attempt to understand the curent logic (explained at a high level later), and still not give up. Often, when you explain how long it will take, they will not want you to do it. The design and coding can be fairly complex and time consuming. Even after it's in place, you will have made specifying autoassignment rules even more complex than it already is. On-going price you pay for autoassignment data maintenance can be much higher, if you are in a very large environment. Bulk of the autoassignment logic consists of around 200 filters on the main forms (HPD:HelpDesk, CHG:Change, CHG:Task), some of them shared by all of these forms. They use information on multiple backend forms and do a fair amount of looping to do the autoassignment. Understanding this logic is your first hurdle, before you can change anything. With 200 filters and multiple looping, it's confusing as hell. Then you have to worry about changing the backend forms themselves, perhaps the easy part. Even before you start coding, however, you have to design on paper your new logic for autoassignment, which is already funky out of the box. Out of box logic (200 flters mentioned earlier) looks for the most specific record on SHR:Assignment form (matching CTI RSD), failing which it looks for less specific one (CTI RS), failing which it looks for still less specific one. What is does is not very intuitive or not even completely logical, in my opinion. There's a KB article on support site that expalins the sequence the filters follow as they loop (search for "autoassignment" ). You will have to figure out where does you new field fit in. Putting it at the end (CTI RSD X, where X is your new field), is not necessarily the right answer. It depends on whether this new field is more of less important than other fields in picking the assignee and how you intened to specify the autoassignment rules on SHR:Assignment. It could take you weeks to get it all done. I haven't done this kind of customization recently and don't have actual code to share with you. If I have not managed to discourage you so far, a lister can perhaps share details of code changes. Regards. -Rabi Tripathi New York --- Tarun Kumar SHARMA <[EMAIL PROTECTED]> wrote: > Hello, > > Is there any Possibility of additional parameters with Skills in > addition to > Category,Type,Item,Region,Site,Dept(CTI-RSD) ? > > For e.g if we want one additional parameter Organization with these 6 > parameters. Is there any possibility that the ticket should be routed > based on these 7 parameters except these 6 parameters. > > If you have experienced such kind of changes, Please share. > > Thanks & Regards, > Tarun > > ________________________________________________________________________ _______ > UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
