As I revised for the MB2-718 exam (Microsoft Dynamics 365 Customer Service) I’m creating blog posts detailing all aspects of my revision. I hope these posts will aid anyone who is also revising for this exam. In this post I will look at queue management.

The skills measured statement that refers to queues is shown below;

What is a Queue?

A queue is simply a list of “work items” including cases, activities or other entity types. Queues are a place to organize and store “jobs” waiting to be processed. Dynamics includes queuing and workflow tools to efficiently manage incoming requests, this post will explain the concepts connected with this management.

Queue Types

There are two different types of queue, personal queues and system queues.

Personal queues are queues tied to an individual user (or team), whilst system queues are available across the whole system. Personal queues can be used to route important activities to individual users. System queues are used for queues of work that need to be shared. (For example: A queue of newly arrived support cases.)

With a personal queue other users do not have access to see the details of the queue. It is possible to configure Dynamics 365 to automatically move items to personal queues as they are assigned.

System queues are a container for work items that a group of people might work on. Queues can be configured for any record type in the system but by default queues are configured to work with cases and activities.

With system queues agents can indicate what queue items they are working on, providing managers the ability to see who is working on what. (And importantly what items are not being worked on.)

System queues can be given a type of Public or Private. Public meaning that the queue is available to all users in the system. Private indicating that it is available to a list of members which can be defined on the queue.

Queues can have an email alias, meaning you can create an email address such as support@mycompany.com and have emails to this address automatically routed to the support queue.

Maintain Queues

Whenever a user or a team is created a default queue is automatically created, this is their personal queue. System queues can be created from the Service Management area under settings. Or in business management under settings.

It is worth understanding that the “queue” option within the Service area actually displays the entity “queue items”. So when you view a queue you see its contents not the definition of the queue.

Below you can see an example of a public queue I have created to handle any incoming support calls. Notice that I have assigned an incoming email address. When you do this an associated mailbox will be automatically created. (Note: Prior to creating this queue I created a suitable shared mailbox in Exchange, thus giving me a generic support email address without needing to create a Dynamics 365 user and consume a license!)

Within the mailbox you can configure how the server profile associated to the email address should behave. Such as configuring server-side sync for incoming synchronization.

When queues are created they are immediately active, they don’t need to be published to make them active. Active queues can be deactivated and reactivated. Queues can be deleted but ONLY if there are no queue items associated with the queue. Meaning that before you can delete a queue you must re-route the items to another queue or delete them before attempting the delete of the queue.

Note: Deleting the queue items removes them from the queue it does not delete the associated record.

The process for creating a private queue is pretty much the same as creating a public queue, except with a private queue you define a list of members for the queue.

Also, having created the queue and mailbox the newly created mailbox will need to be approved and tested before it will operate. As (in my example) I wanted a generic shared mailbox for incoming support issue sonly I have not configured outgoing email. I have also opted to delete the email messages once they have been processed.

Once the queue has been created you are ready to add queue items to the queue. With emails this could be automatically handled on the receipt of a new message, with cases you can use routine rules to automatically route cases to the queue. (Such as automatically move high priority cases to an escalation queue.) These options will be covered later in this post.

Or you can manually route items directly to the queue as required!

Add Cases / Activities to Queues

Now we’ll look at how to manually route a case (or other activities / entities) to a queue. From the case form you can access the “Add to Queue” option. Once selected you and chose the queue you’d like to move the case onto. In my example I have selected the “Support Calls” Queue.

Now the case is allocated to the queue, I can see it by looking to the list of active items in the “Support Call” queue. You can also see the details of the queue the case is on by using the “Queue Item Details” button from the case. This will present a screen something like the one below. Notice that this allows the user to see which user is working on the case. (Worked by) This field is set as users are assigned to the case or they pick the case from the queue.

Note: If the case is already assigned to a queue the “Add to Queue” button still shows, in this situation the “Add to Queue” button would effectively remove the case from the first queue and move it to the new queue. An entity can only exist one queue at any moment in time.

When we add a case to a queue, behind the scenes nothing is really happening to the case entity. But a new queue item is created on the required queue to show that this case is the “list” of items to be processed from the queue. You can also move one (or more) items to a queue from an active case view. See below that you can select one (or more) cases and then select the “Add to Queue” option from the common bar from the view. This approach is useful when allocating several items in one go or when you want to quickly move something to a queue without opening the record.

The process for adding activities (or any entity enabled for queues) to a queue is pretty much the same. Although I suggest you experiment with a few entities to become familiar with this process. Below you can see I have added a phone call, case and email to the same queue. This also demonstrates that you shouldn’t think of a queue in terms of one entity type. In my example, it would be quite common to have a support queue that includes multiple entity types all of which need attention from someone in the support team.

Queue Items

So having routed one or more items, next we’ll look at how to work with the items on a queue.

A queue is simply a list of queue item records. Therefore, a queue is not a collection of records but a collection of queue items. What is routed to the queue is not the record itself but the queue item record. Meaning the queue item is a go-between record sitting between the record and the queue. In the service module when a queue is selected from a view the system is actually filtering the queue items by the queue selected. If you inspect a queue item you see no details about the actual case / activity associated, the queue item will simply state who is working on the case and when it entered the queue. This does mean it is quite a common customization to add additional information to the queue item, for example priority might be useful on a queue item in some organizations.

The drop down of queues will contain a list of all available queues, you also have their other options that might be useful to filter queue items. Including looking in all queues, all public queues or all queues the operator is a member of. These options are useful if a single person needs to monitor multiple queues.

Having selected an appropriate queue(s), you can then change the view to show;

• all items,
• just items you are working on,
• items that are available
• etc.

Using these views enables an operator to see work they have “to do” and work they “could” do.

The items someone is working on or items that are available is governed by the “worked by” field on the queue items. Meaning you’d either be looking at all queue items with the worked by set to the current user (your to-do list) or all items with a blank worked by (your “could do” list). The worked by field will remain set to the current user until the queue item is completed or the queue item is “released”, which effectively wipes the worked by field and puts the queue item back into the “pot”.

Pick Queue Items

From the queue you use the “pick” option to show when you are working on a case. (or other queue item.) Highlight one or more available queue items then select the pick option, this will present a dialogue similar to the one below. Picking the queue item will assign you as the owner. You then have an option to remove the item from the queue or not. If the item remains in the queue the “worked by” field is also set to show that you are now managing the case.

See below that I left the items in the queue so the “Worked By” field has been set to me.

You can also use the route option to move a queue item from one queue to another. Or in the route dialog select a user (or team) to allocate to the queue item. And again an option is presented to remove the queue item (or not). The owner and worked by fields are then set in the same manner as someone picking the queue item, except the selected user is used instead of the current user. This approach is typically used when a team leader “dishes out” the queue items rather than the operator picking them.

Release / Remove Queue Items

Let’s say you are allocated some cases you can’t do, maybe your about to take a holiday and need to release current activities to ensure that someone else processes these items whilst you are away. This is done by using the release option from the queue. Simply select the item(s) you wish to release and select the release option. This approach leaves the queue items in the queue, “waiting” for someone else to pick them up.

An alternative approach would be to use the “Remove” option. This however would remove the items from the queue. When considering the remove option it is important to understand that only the queue item is removed not the associated case / activity.

Note: Directly from the case you can add the case or route the case to the queue. But to pick and release the queue items you are required to do this from the queue views.

Case Routing

Another important aspect of managing queues is the concept of case routing. Within a service management environment the use of queues is very common. The ability to automatically route cases is a really effective way to help with the management of queues. The automatic routing might be based on a characteristic(s) if a case, for example all new installation requests to be sent to the installation team’s queue or all high priority requests to be sent to a “High Priority” queue.

Auto-routing can be applied when a new case is saved or whenever a user uses the “save & route” option on the case.

Note: If you are using auto-save, it is important to understand that the case is not routed when the auto save kicks in! The routing happens when the use selects the “Save & Route” option.

Routing rule sets are defined in the service management area of Dynamics 365.

Below you can see a silly example of a routing rule set but one that hopefully illustrates the concept. I have created a rule set that will assign new cases to my cat!

Each routing rule set can have one or more rule items. Below you can see I have added one example rule item. In this example I am assigning the case to a user but you can see that I also have an option to route cases to a queue. The logic is simple enough, whenever the condition is met the case will be assigned to a team / user or routed to a queue as required.

I’m describing queues in the context of service management but it is important to understand that queues could be used by other parts of the business, for example, all fresh leads might be assigned to a new leads new leads queue.

Cases and other entities can be routed to shared queues (private system queues), system queues (public system queues) or even personal queues.

Tip: A very effective way to manage case routing is to use this concept of routing rule sets. However an alternative approach would be to have a workflow that is triggered when a case is created, this could then create appropriate queue items based on the case detail.

In this post I hope I’ve given you enough background information on queues to support your preparation for the MB2-718 exam. But as always I strongly ecourage you to gain as much hands-on experience as possible.