Multi Queue Priority

Enables the system to assign priorities to queues allowing for a predetermined order in which tasks are routed to agents. There was no predefined order for invoking queues before this.

Priority Range:

• We can assign a priority to a queue within a range of 1 to 10, with 1 being the lowest and 10 being the highest.

Chats Distribution Order:

• Step 1: The system considers the Queue-Priority first. Tasks within high-priority queues are routed first. (Within a single queue, task priority will be considered before FIFO).

• Step 2: If multiple or all queues have the same priority, The system considers the Task Priority within all queues. Task with the highest priority (regardless of the queue) will be routed first, then the second highest priority task will be routed and so on.

• Third Step: If both queue and task priority are the same, RE considers the longest waiting task to be routed in that order. 

Enable/Disable Queue Priority

By default, the value for queue priority is set to false. However, it can be enabled or disabled again. To enable/disable this, follow these steps:

1. Update the value of IS_QUEUE_PRIORITY_ENABLED in the file cim-solution/kubernetes/cim/ConfigMaps/ef-routing-engine-configmap.yaml as required.

   • The value should be in double quotes: "true" or "false".

2. Navigate to the ConfigMaps directory, then delete and reapply the Routing Engine configmap:

   CODE

   k delete -f ef-routing-engine-configmap.yaml  
   k apply -f ef-routing-engine-configmap.yaml  

3. Navigate to the Deployments directory, then delete and reapply the Routing Engine deployment:

   CODE

   k delete -f ef-routing-engine-deployment.yaml  
   k apply -f ef-routing-engine-deployment.yaml

Technical Flow:

The technical solution and flow for this feature can be found here.

Limitation:

When an agent is in the RESERVED state (due to a chat request), he will not receive requests from other queues during that time. Upon accepting the chat, the agent continues to miss requests from any other queue because only the queue associated with the accepted chat request is invoked. Since other requests are on different queues, those queues are not triggered.
This behavior will only occur if there is a single agent available and that agent is in the RESERVED state. If a request comes in while the agent is reserved, that request will not be routed to that agent on accepting the reserved chat. The request will only be routed if the agent manually changes the MRD associated with that queue or if another agent becomes available.