From this release, you can create multiple criteria-based queues for each organization. However, each organization will continue to have a DEFAULT queue, as was the case in previous releases.
The Matched Rule and Risk Advice values of the first transaction of a case decide which case is assigned to a queue. For example, if a case was created due to the Userknown-Alert transaction, then throughout the life of the case, the Queue Criteria will use this value, even if a DENY transaction gets added to the case later.
A transaction with the highest risk score is called the "Riskiest Transaction". Risk Advice and Risk Score of the riskiest transaction in the case decide the overall case Risk Score.This case Risk Score is used to prioritize cases within the Queue. While the case remains assigned to the same queue even if new transactions get added to the case, the priority of the case gets changed if a new transaction with higher score is added to the case.
Before you delete a Queue, it is highly recommended that you edit the Queue definition such that no cases are present in this Queue, refresh the cache, rebuild the Queue, and then delete this queue. This ensures that cases, which were in this queue, are not lost.
With support for multiple queues, you must note that:
Queue Managers must issue a Queue rebuild for the changes to take effect immediately. Else, the changes come into effect when the regular automated Queue rebuild happens (at a default frequency of 30 minutes).
Note: A change in Customer Support Representative (CSR) assignment to Queues still requires a cache refresh.
|
Copyright © 2013 CA.
All rights reserved.
|
|