Case Accountability with Queues

Cases and Queues tend to go hand in hand in MS Dynamics CRM.  It is a great concept that you can route cases of a certain type to a designated queue, where specialized workers can pick the case and start working on it. One of the most important disciplines in case management, is establishing clear accountability on every case at all times. There should not be any discussion or ambiguity as to who’s got the ball at any given moment. This is where queues have a few pitfalls and challenges that implementers should be aware of when establishing processes.

How do queues establish accountability?

Queues use a Queue Item for every case that has been routed or added to a queue. The queue item includes a “Worked By” field to identify if anyone, or who is working on the item. When a queue item is picked, or routed to a user or team, the queue item remains, and the Worked By is updated the User or Team. In addition, the Case is assigned to the User or Team it was routed to. If a queue item is released, the case is assigned to the Owner of the queue. Which can be either a user or team.

In this context, most of the actions around queues, populates the “Worked By” field AND assign the case to the same User or Team. This implies that “Worked By” and Case Owner are in synch and there is only one responsible entity. It is clear who is accountable. However, one of the before mentioned pitfalls occur when a queue item has been routed to a User or Team, and afterwards the case is assigned to somebody else. In that scenario, there is now a mismatch between “Worked By” and Case Owner and a great opportunity to have a case fall between the cracks.

Queue Actions	Worked By	Case Owner	Owner/Worked By Match
Route to User or Team	Sets to User or Team	Assigns to User or Team	In Synch
Pick	Sets to Self	Assigns to Self	In Synch
Release w Worked By	Clears Worked By	Assigns to Queue Owner (User or Team)	n/a
Remove	Deletes queue item	No change	n/a
Case Actions
Assign with no Worked By	n/a	Assigns to User or Team	n/a
Assign with Worked By	No Change in Worked By	Assigns to User or Team	Risk of Mismatch

Routing to a Queue

You would assume that routing or adding to a queue would always have the same action. This is not the case. If a queue item has “Worked By” populated and you from the case form add the case to another queue, the user defined in the Worked By remains. Same if you apply a routing rule and it runs automatically. However, if you from the list of queue items, also select the “Route to Queue”, the “Worked By” field will be cleared and whoever was responsible, is no longer responsible.

Adding or Routing to a Queue	Worked By	Case Owner
Add to Queue from Case form	n/a	No Change
Route to Queue from queue list	n/a	No Change
Route to Queue with Worked By	Clears Worked By	No Change
Route via Routing Rule with Worked By	Worked By remains the same	No Change
Add to Queue with Worked By	Worked By remains the same	No Change

Some Queue Pitfalls

Queues has a few pitfalls and quirks that are worth being aware of when designing and implementing case management. We will go through those items one by one:

• Queue Items not visible directly on the Case form
• No warning when routing to a new queue and removing from the existing queue
• No Audit History for queues on the Case
• Route to a Personal Queue does not assign the Case
• Reactivating a Case can create multiple Queue Items
• Deleting a Queue Item will delete the Case

Queue Items are not visible on the Case itself

Users cannot see, on a case, or from a case view, which queue it belongs and who may or may not be in the “Worked By”. A User would have to open the case and click on the “Queue Item Details” button to see the information.

No Warning When Routing to a New Queue

While Users do not have direct visibility on the queue details directly on the case form, they can still add the case to other queues. And in doing so, there is no warning to let the user know, that the case is already a member of another queue.

No Audit History for Queues

Queue Items are fleeting records. As soon as a record is removed from one case, the queue item is deleted from the system. You cannot go back and look at the Audit History to see which queue a case has belonged, nor do you have access to any time stamps of when the items were created or had a “Worked By” added. You only have access to the Audit History on the Queue Item if you never broke the chain by removing a Queue Item.

Route to a Personal Queue does not Assign the Record

If you take a case or a queue item and route it directly to an individual If you add something to a user’s individual queue, the case does not get assigned to that individual. The “Worked By” on the queue item will be empty and the case will remain assigned to the current owner. I would have expected an assignment as well since an individual was identified in this process.

Case Resolution and Reactivation can create multiple queue items

When you resolve a case that is in a queue, the queue item will deactivate and remain with the case. However, if you reactivate the case, the queue item will remain inactive. This by itself does not cause any issues, but if the case is then added to another queue, a duplicate queue item will be created. In turn, you will get this error message when trying to view the queue item from the case.

Deleting a Queue Item Will Delete the Case

While you can’t delete queue items from the view, you can delete them when you are in Advanced Find. Handle with care though as deleting a will also delete the case (or other record) the queue item is for. Stick to using the “Remove” button as it will effectively just delete the queue item and not the case itself.

Best Practice on Case Accountability

There are however, methods to get around these pitfalls using simple configurations and workflows. Using lookup fields in CRM to both the Queue and the Queue Item entity, it is possible to leverage workflows to keep these fields updated with the Queue and Queue Item. This will allow you to add details from the Queue and who the “Worked By” is to the case form itself. No additional clicks to get to the information. This will also keep your Audit History for queue movement. In turn, workflows can also be leveraged to keep the “Worked By” and the Case Owner synchronized if that is desired.

Lookup fields to both Queue and Queue Item can also be enabled for auditing making it easier to backtrack what happened in case there are issues. While you cannot use the security roles to stop people from removing Queue Items, real-time workflows can be leveraged for this. Or the Remove button can be removed from the menu. Pun not intended. Workflows can also be used to reactivate a queue item when a case is being reactivated. This will avoid issues with multiple items for one case and will keep the history on the Queue Item as well.

Conclusion

Understanding how queues work and what some of their pitfalls are is extremely helpful during an implementation. At Elev8 Solutions we are happy to help you working with queues and have years of expertise in establishing proper accountability for your cases and ensuring proper follow through.

Are you ready to put these Expert Insights to work in your Dynamics CRM environment? Contact us today for a free demo or business assessment.