I have recently written a few blog posts which describe some of the features of Unified Routing with Dynamics 365. In the main those posts have focused on scenarios connected with Omnichannel for Customer Service but in this post I will explore using Unified Routing with "just" Dynamics 365 Customer Service. As we should be mindful that Unified Routing is a "stand alone" feature that can be applied to many use cases.

A couple of my recent posts are shown below;

It maybe common to use Unified Routing to route cases and emails within a contact center and then it will be likely we'll be using Omnichannel for customer service. But Unified Routing can be deployed without Omnichannel!

You actually "only" need a customer service enterprise license to use Unified Routing. Although the basic license only grants the routing of 50 records per agent per month. However it is possible to buy an add-on to increase this capacity if require. I have shown an extract from the current licensing guide which highlights that the record routing found in Unified Routing is past of the "Customer Service Enterprise" license.

Typically we will use Unified Routing with either the Customer Service Workspace app or the Omnichannel for Customer Service app. Both of these apps give us the ability to control an agents presence and also define how sessions should operate when a record is opened. However I would like to flag that we can also use the Customer Service Hub to manage routed items. Although the user experience isn't as "rich" as the capabilities provides by the "multi-session" apps. (I will show this later in this post!)

I "obviously" already have Omnichannel for Customer Service installed in my environment! So as a test I created a trial which was just a Customer Service Trial, doing this gave me an opportunity to test out Unified Routing and the Customer Service Workspace app without Omnichannel.

In the rest of this post I will explain how I configured my trial, commenting on any tips I have along the way. The idea of this test wasn't to create anything "special" about the routing! It was actually quite the reverse, I wanted to explore the minimum setup needed to route cases to agents.

Below you can see that within the Customer Service hub in the Service Management area I can access the Unified Routing options. (These options are also available from the Omnichannel Admin Center, if you happen to be using Omnichannel!)

I wanted to test the most basic setup! But before I can use Unified Routing I needed to check it was enabled. You probably need to be aware that once enabled this feature cannot be disabled, so you probably want to test this out in a trial or sandbox first! Below you can see that in the "Service Configuration" option I selected the "Turn on unified routing" setting.

Additionally before you being using the Unified Routing option, I believe, an admin will need to grant permissions to the "Omnichannel" APIs. So I used the link below to grant the permissions before continuing.

https://go.microsoft.com/fwlink/p/?linkid=2070932

I first created a queue using the "Advanced queues" option. You need to use this option instead of the normal queues option, as this approach will prompt you to define the queue as a record or messaging queue. My queue was a record routing queue and I simply added my user(s) into this queue.

Some user setup may need to be considered … If you open the user's record you will notice an Omnichannel tab. (Yes "Omnichannel", and no we aren't using Omnichannel!)

Some options you might want to consider include the agents capacity, as this will impact the number of records they can handle concurrently. Here you will also see any messaging or record queues this agent is a member of.

Importantly, you will need to create a bookable resource for this user. This can be really useful if you wish to assign skills to a user which can be used to route the correct records to the agents with the right skills. But in my setup I didn't want to define any skills. But I still needed to create a bookable resource.

Next I created the definition of my record routing. I kept this to a minimum! Meaning I created a workstream which simply routed everything to the queue I'd created. And an intake rule which routed all cases to my workstream.

Tip: I could have added conditions to my intake rule (and / or routing rule sets), maybe to route only high priority cases or maybe only cases from a particular origin but this experiment was aimed at having a super simple setup!

My workstream was also super simple!

I accepted the default settings for work distribution. Meaning I'd have a "push" distribution mode and all presences would be allowed. Typically I would only route records to agents that are available or busy (but with capacity). But by effectively "ignoring" presence I was able to achieve "play with" the customer service hub …. something I will mention later in this post!

I also created just one routing rule set. Again I kept this super simple! I had no condition and simply selected the record queue I'd created. Meaning all cases will be routed to the same queue.

If you are going to create your cases on a portal or maybe create them using a record creation rule then you are ready to start testing. As newly created cases by default will route. BUT … as the note below explains cases that are created directly in the user interface will not automatically trigger the routing logic.

Tip:
I have found that I can also use the "save and route" option on a case to manually force the routing to be triggered! This is actually really useful if you want to route a case that already exists.

However, I'm lazy! And I wanted all my new cases to automatically route. Including those created directly in the user interface. For this you can (optionally) create a Cloud Flow. The link below is from Microsoft and will explain the process. Which is actually quite straight forward … all you need to do is trigger an unbound action when a record is created or modified.

Route records automatically using custom flow | Microsoft Docs

Tip: I say this step is optional as you maybe trying to route cases created outside of the user interface and then you simply don't need this step. You should also keep in mind that we could be routing a record type other than case as then you would always need a Flow as they will not route by default.

Below you can see the CloudFlow that I created. Basically It was triggered whenever a case was created, I then added a condition to only trigger my action if the "Route Case" field was false. (As it could be that the default routing will have already been triggered!)

Tip:
This idea worked well for my example. But in real-world scenarios I doubt you'd follow this approach. I actually think it makes sense to not route cases directly created in the user interface! As the person creating the case will typically already be working on the case, so why route it! I've only included these details to explain the concept of how records "could be" routed using a Cloud Flow if required.

Customer Service Workspace

Now in the Customer Service Workspace app when cases are created my agent will be assigned to the case and they will see notifications as work items are assigned.

Tip: Maybe confusingly (as we aren't using Omnichannel) within the Customer Service Workspace your agents may find it useful to use the "Omnichannel Agent Dashboard" to see their work items.

Customer Service Hub!

The customer service workspace app is certainly the app that will give the best user experience. As that will include notifications when cases arrive and your agent's presence will also be known. Additionally, don't forget, that with the Customer Service Workspace app we can define productively aids like agents scripts or define how sessions open.

But if you recall, in my opening I created the distribution approach to work with all agent presences. I did that so I could attempt to use just the standard Customer Service Hub. All be it with some limitations!

Below you can see that I was pleasantly surprised how cases routed to me using Unified Routing were also showing correctly within the Customer Service Hub. Meaning I could use the "traditional" queues option to manage my work. (Although I will stress again that the Customer Service Workspace does have additional capabilities!)

I am not going to recommend you currently consider the Customer Service Hub for all scenarios but in low volume / simple setups I see no real technical issue in using just the Customer Service Hub. Additionally (I imagine) if you are already using the Customer Service Hub this concept maybe a useful stepping stone towards the richer experience found in the Customer Service Workspace app.

I hope in this post I have given you loads to think about when considering how to route cases (and other records) to agents without implementing Omnichannel for Customer Service. Enjoy.