How does Round Robin Logged In work?

Environment:

Incident Queues - Round Robin
Oracle B2C Service, All versions

Resolution:

The Round Robin Logged In queuing logic has general guidelines that controls when, how, and who the incidents are routed to.  There is a logical bucket of incidents that are flagged as 'overflow' which is used to manage incidents that do not meet assignment criteria.  This bucket is defined and controlled by the product and cannot be customized to meet your business needs.  The round robin logic can be affected by the way the site is configured and incident assignment can be triggered in a variety of methods.  An attempt is made to distribute incidents in a round robin fashion but this does not mean they are 'load' balanced nor does it mean every agent will have an equal chance of getting incidents assigned to them.  Some of the triggers are listed below:

• Manually assigned through the assigned field either explicitly or through a workspace rule
• Fill inbox is pressed by an agent
• Incident is created or updated and are handled differently in order for new incidents to not get routed prematurely
• Other incident solves will trigger the queuing logic to route the overflow incident bucket
• Dbstatus utility executes
• Server rule updates an incident field

The dependencies for the queuing logic Round Robin Logged In queues includes the number of queues and queue types included in the profile settings, pull policy, pull quantity, inbox limit, pull from single Round Robin Logged In queue, incident created date, and the activity on the site. We are defining the use of 'position' below as the agent who would receive the next incident if we were dealing them out like a deck of cards. Say we have 5 agents logged in, and our current position is agent 3.  If something updates the 'position' that means we move to 4.

The variability in this logic may include:

1. Manually assigned incidents effectively bypasses any automatic queuing type logic and the round robin 'position' is not updated
2. Fill inbox pulls incidents from the overflow bucket and the round robin 'position' is not updated.
3. When an incident is created, it will be put in the overflow bucket until another trigger occurs. 
4. When an overflow incident is updated, the applicable queuing logic is executed to see if it can be routed to an available agent.  The round robin 'position' is updated.  This does not take into account the single versus combined round robin profile design option.  It treats all incidents as if they are in one large overflow queue
5. When an agent solves an incident, if the current number of unresolved incidents assigned to him is below his inbox limit, the queuing logic is executed.  The agent will be assigned the oldest incident available to him.  If the profile option is set to only look in a single queue, the oldest incident in the queue where the solved incident was in will be assigned to the agent (basically it inherits the solved incident's queue for the round robin logic).  The round robin 'position' is not updated.
6. Dbstatus runs at a set interval and checks to see if any incidents in the overflow bucket can be routed. It will route as many incidents in the overflow bucket up to 100 during each interval.  Dbstatus ignores the pull policy and pull quantity profile options and uses the created incident date when determining the oldest incidents.  Dbstatus does not take into account the profile option that signals whether a single or combined queues should be used.  The round robin 'position' is updated.