Customer Service Basic Queues. Should You Use Them?

I’ve recently been speaking to several people about queues and the reason for the existence of queues. It’s believed by some that views and the ability to assign records are sufficient and that queues are unnecessary or unnecessarily complex. In this blog, I’ll explore basic queues and share my understanding of when queues are in fact the ideal choice in a solution. 

What are Queues

First off, what exactly are queues? According to Microsoft Learn,

“Queues are containers used to store anything that needs to be completed or requires an action such as completing a task or closing a case”.  

Queues are typically used to route cases or tasks to a user or group of users who need to complete an action on the record. This is noticeably different to assigning a record to a new owner. 

The below scenario shows an example of how queues are typically used:

A case is created and owned by User A. They are ultimately responsible for the resolution of the case. However, they are not able to resolve the case without input and support from other departments. 

In this situation, there are a few options that can be applied based on the needs of the business. I’ll expand on two of these options:

1. Tasks could be created for the necessary departments allowing for work to be completed in a parallel fashion. This is ideal if there are no dependencies between the departments and could help the case to be resolved faster. 

In this scenario one could argue that the task should be assigned to the department and not added to the department’s queue. Read on to find out some of the key benefits of using queues and let me know in the comments if you would still choose to assign the task to a department vs use a queue. 

2. The case could be directly added to the queue of the department that needs to take action. This is ideal if there are dependent activities for this case to be resolved. 

Why Queues?

Although queues look similar to a standard D365 view, there is a lot more functionality hidden behind them. In the above example, we used queues for a few reasons:

1. Accountability:

Assigning the tasks to the department would not allow us to know who in the department was working on it and how long they’ve had ownership of the task without additional development effort. 

When a record is assigned to a queue, a queue item is created which has details of the queue, the record and the date the record entered the queue. This field is updated each time the record is added to another queue. 

Queue items are visible to users who belong to the queue and if a user chooses to work on the record, they can “Pick” the queue item. This action adds their name to the queue item record and allows other users to see that the item is being actioned. Items can also be released to notify that the record is no longer being worked on by the user. 

This is visible by clicking on the queue button in the command panel on the applicable record. Doing this allows users to quickly see if the record is in a queue, the date it entered the queue as well as the user currently working on the record. 

2. Security 

In some companies, there may be a need to separate items being worked on and allow only some users access to the fact that these items are being worked on at all. There are two main types of queues in Dynamics 365; public and private queues. 

• Public queues and their content can be seen by all users in the system.

• Private queues and its contents can only be seen by it’s members. 

It is Important to note that private queues should not be used to replace security roles but should be used in conjunction with security roles. The actual records within the queue will still be visible by users according to the security roles defined.

3. Business Process Automation

Allowing automation rules that relate to the KPIs or SLAs of various departments to be triggered based on the creation or modification of a queue item would allow a more accurate and effective case management journey. 

For e.g., if one of the tasks assigned had entered the queue for department B over a week ago, it will be easy to trigger an escalation process related to that task with the details of the case associated to it. There is no actual update to the case record, but this escalation can be visible in the timeline of the case record. To achieve similar functionality via assigning the task or case record to a new owner would require additional development as the records can be assigned to different teams and also to different users. 

There are other benefits to using queues, such as being able to automatically create records such as cases based on Automatic Record Creation rules which are tied to a queue. Queues can be associated to email addresses which allow records to be automatically created based on the configured rules and which will allow the record to be added to the queue once its created.

In this blog, I’ve provided a few reasons to choose queues vs automatically assigning the record. I will of course point out that each scenario and solution is unique. Therefore, there may be a need to forgo using queues. However, before ignoring this gem of a feature in the Customer Service catalogue, check out if it can natively meet your needs and give it a shot!