I finally got an use case to implement Camunda, but stuck with something. Hope you can clarify.
Our use case is
The idea is to use camunda workflow/tasklist as a queue to handle support requests/queries. So, agent can pick up the task (by claiming it) from the group, call the customer and resolve the case.
But the problem here is, since agent can see all the tasks with-in the group, they usually tend to pick up the easy ones based on the description of the problem. That way by EOD they would have completed more tasks. Agent gets one entry into prize draw for every task he completes (internal thing ).
But what we want to find out is, if there is any possibility of queuing all the queries/tasks hiding away from the agent. So when agent is free, he can come and say “Get me next task from queue” and at that point a task needs to be assigned to the agent. This approach gives everyone a fair chance. Wondering if it’s possible to model this approach in BPMN.
Any thoughts/suggestions are welcome.
Thanks for your time.
You could consider adding some logic to task assignment and claiming. Hence on task creation if length of unassigned tasks less than threshold then assign to group else assign to shadow group. On task claim, get next task from shadow group and assign to accessible group. You may be able to achieve this via task listeners and use of task api…
Thanks for your quick reply @Webcyberrob Appreciate it.
Looking at TaskListener details @ https://docs.camunda.org/manual/7.4/user-guide/process-engine/delegation-code/ and it appears TaskListeners can be configured to create, assignment, complete & delete events only. Any idea how to override/extend/handle “Claim” event?
Here’s a snippet I found in the consulting examples. Note it could be quite advanced. It looks like it overrides the claim function in the tasklist with a custom function which ensures that the person claiming the task has not had prior involvement. Hence you could consider something similar to enforce that a person can only claim the next task in order of creation, or a task from the top ‘n’ in order of creation etc.
Another mechanism which comes to mind, again based on maintianing a window of unassigned tasks in order of creation - use a task completion handler to move a task from the ‘shadow group’ to the avaialble group. Note if you go down this path, beware of ‘starvation’, ie tasks avaialable but not in the unassigned list…
In addition to Rob’s explanations, note that claiming a task also triggers the
assignment event since it sets the assignee, so a TaskListener should work.
Thanks Rob & Thorben. I will check this and come back to you.
Hope it’s ok if I have to bother you again!