I am currently revising for the MB-230 exam. This exam is for Microsoft Dynamics 365 and covers all aspects of customer service. As I revise I plan to publish blog posts that collectively will become a complete revision guide for anyone embarking on the same journey as me. In this post I will begin to describe the concept of queues.
Below you can see an extract from the skills measured statement of the MB-230 exam. Notice that we’ll need to know how to configure queues, add cases to queues, configure tables (entities) for queues and more.
What is a Queue?
Let’s begin with a simple question …. “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 365 includes queuing and workflow tools to efficiently manage incoming requests, this post will explain the concepts connected with this management.
From a customer service point of view queues can be a very important concept to allow teams of users to manage incoming requests for service, as they can be routed to suitable queues to ensure the right agents work on the correct pieces of work.
Note: In this post I will not be discussing additional concepts we have within Omnichannel for Customer Service. As with that there is a concept of a messaging queue which is used to route conversations to agents. (I will cover those concepts when I review Omnichannel!)
There are essentially two styles of queue, user queues and system queues.
User queues are tied to an individual user (or team), whilst system queues are available across the whole system. User queues can be used to route important activities to individual users. Each user will have a queue (local user queue) created automatically as their system user record is created. 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 local user queues as they are assigned.
System queues are used for queues of work that need to be shared. (For example: A queue of newly arrived support cases.) 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 enabled 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. With a private queue you must be a member of the queue to see the queue items.
Queues can have an email alias, meaning you can create an email address such as email@example.com and have emails to this address automatically routed to the support queue. (We may then also use an automatic record creation rule to create cases as emails arrive on this queue.)
As one example, below you can see an example queue definition. Notice that in this example the queue type is “private” and therefore the queue has a number of members.
Whenever a user or a team is created a default queue is automatically created, this is their “local user queue”. This shouldn’t be maintained! But system queues can be maintained in the queues option which can be found in the service management area of the customer service hub. (As shown below.)
Additionally queues can be created from the Service Management area of the advanced settings. Or in business management option within advanced settings.
It is worth understanding that the “queues” option within the customer service hub’s service area actually displays the “queue items”. So when you view a queue from here 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!
When queues are created they are immediately active, they don’t need to be published to enable them. 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 remove 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.
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 routing 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 “Urgent Cases” Queue.
Now the case is allocated to the queue, I can see it by looking to the list of active items in the “Urgent Cases” 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 (and change) which user is working on the case. (aka the “Worked by” field.) This field is set as users are assigned to the case or they pick the case from the queue.
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. A record 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 in 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 command bar above 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 task to the same queue. This also demonstrates that you shouldn’t think of a queue in terms of one entity type. 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.
Tip: This does mean I named my example queue badly! As I called my queue “Urgent Cases”. This queue could actually include entities other than just cases, so a better name might have been something like “Urgent Support Enquiries”.
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. 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.
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
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.
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.
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.
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 the customer service hub.
Below you can see an example of a routing rule set, one that hopefully illustrates the concept. I have created a rule set that will assign new IoT cases to my cat! And any high priority cases to my urgent cases queue.
Each routing rule set can have one or more rule items. Below you can see I have opened an example rule item. In this example I am assigning the case to a queue but I hope you can see that I also have an option to route cases to a user. 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.
You cannot amend an active Routing rule set, So you will need to deactivate it to make changes. But don’t forget to activate again as only activate rules will be applied when you apply the routing rule.
Enabling Other Tables for Routing
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.
Which tables are enabled for queues can be customized.
Below you can see that I have opened Power Apps (make.powerapps.com) and then opened my invoice table. Here I can access the settings option to control how this table (aka entity) will behave. You will find the options relating to queues under the “Collaboration” heading.
Below you can see I can now use the “Enable Queues” option to allow me to route records in this table to queues. One thing you should be aware of is that if you make this change it can not be reversed. Once a table is enabled for queues it cannot be disabled!
Also notice that we can also opt to add newly created records to the owners local user queue.
In this post I hope I’ve given you enough background information on queues to support your preparation for the MB 230 exam. Queues are actually a simple enough concept but I have found some Dynamics 365 consultants can become confused about how queues operated and when to use them. So as always I strongly encourage you to gain as much hands-on experience as possible. Enjoy!