Ticket assignment rules for operators in assignment groups

Hi all, 

We have requirement to assign tickets to operator in assignment groups based on conditions. 

For ex: In assignment group--network if there are four operators a,b,c and d and then how to assign tickets equally among them based their ticket load(Number tickets each operator is handling).

  • Hello,

    Are you sure you really need that? Think it will be heavy solution and there will be problems if people will be in different groups at the same time. Maybe it is better to make 1 group manager which will be controlling the load on the operators inside the group.

  • Hi Vadim,


    Thanks for the reply as always..


    I agree, this is quite heavy stuff(that to considering HP Service manager) but in real world scenario it makes sense as considering 1000s of ticket each hour and to assigning them manually is not idealised.(Might be this is biggest drawback of this tool at operational level, as in BMC remedy ITSM tool assignment can be done automatically(That's why it is best in ITSM part) and also you can choose rules like Round and Robins etc they called for the automatic assignment, so tickets are assigned automatically to users based on their work load.)


    This feature has to be there for HP Service Manager too, this is my perception.


    Waiting for reply from your side.

  • Hello abhijitkhewale,

    Nothing proper comes to head at the moment. First thought was that in format control add a query (or in JS) which will count all records assigned to some persons in the current assign group. And after it counted the number of the assigned tickets to each person in the group assign it to lowest one. But not sure that it wont critically affect the system productivity. If any other thought will be born i will post it here

  • Thanks Vadim,


    Another approach was suggetsed by John Stagaman to add the field to operator table to store number of incidents. As to query database everytime is not best practise(say in an assignment group their are 40 operators which might be member of another assignment groups, so for couting each operator's number of ticket we have to query 40 times, this might lower server performance).


    so increment and decrement this field's value according assignment, reassignment and closure.

  • Hello,

    I was thinking about that as well. Any way you will chose it will require huge tailoring and a lot of testing which will include proper increment  and subtraction from counter at the needed condition.

  • Hello Vadim,


    This is a tricky solution no matter how you slice it.  You would need to do one of several things


    A) Build a process the checks all the various rules, and attach that process before the save within the document engine

    B) Create a table and script to process the rules.


    I would recommend doing this with the help of PSO, or some other consulting firm.  This will involve a massive tailoring effort and their are a great deal of potential problems that can arise.  Keep in mind also that this would be a major tailoring effort and would not necessarily be covered by support.


    Hope this points you in the right direction

  • While something like this would certainly present challenges, it is definitely not an insurmountable task.


    My two questions would be:

    1. Does it need to be flexible? Or is auto-assignment based on current ticket load the most important thing? I ask this because building specific functionality to handle load-based assignment would be significantly easier than say, a fully built-out flexible rule system.


    2. I'm assuming that when the ticket is created the assingment group is known - is this definitely the case?


    Running a count of records every time a new Incident is creative would be a very expensive operation if you have a high volume of tickets, but doing something like simpler round-robin processing would be possible with some creative scripting and the addition of a few fields or table.

  • I guess I would suggest two things.

    One is create an assignment group for this and send a notification to that assignment group with those 4 members in it and not just the 4 individuals. It will notify all of those individuals for you. Then they can change to whom the ticket is assigned.

    Secondly you could create 4 tasks for this ticket, or 4 related child module classes(Change Request to 4 associated Tasks)


    If that doesnt work I would just stick to creating seperate tickets for the people since you have it automated anyways.

  • Hello Justin,

    Multiplying the number of tickets by 4 (in fact the number of operators I think will be a lot more) will cause such growth of objects that they wont be able to do anything with such number of tickets. In one of the top posts there was written that there are thousands of incidents which must be auto assigned and if you multiply it by 4   . . . You can count yourself what it will produce.

    Regarding 1 group for assignment, this wont increase the reaction speed, they will have to dig in the records which should not be assigned to their group at all, like Soft Developers will see 1000 incidents for Network group and vice versa which will make such group view unhandled.

  • Performance and synchronization are two major factors to consider when designing this solution.


    Also, what should happen when:

    ...a user manually assigns/reassigns a ticket?

    ...the assignment group changes in the ticket?

    ...a user is not available (illness, vacation, leave of absence)?

    ...a critical ticket is opened during off-hours?

    ...the number of tickets assigned is not evenly distributed?

    ...the assignee is different from the ticket owner?

    ...the ticket is locked when the solution tries to assign it?

    ...a user is a member of more than one assignment group?


    In order to avoid having to constantly count large files, it will likely be necessary to create custom files and fields which track the assignment of tickets. Triggers (JavaScript) will probably be needed to maintain the accuracy of the data. A background process will be needed to synchronize the data (make sure it is processed in an orderly fashion).


    As stated in previous posts, this will require major customization and testing. Make sure to identify all of the requirements before designing the solution.