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 describe the record routing options of Omnichannel for Customer Service.

You can see an extract from the current skills measured statement below. What we can immediately see is that Omnichannel for Customer Service covers a large section of the exam! And also that this topic includes numerous subjects for us to revise. I will attempt to cover as much information as possible in a collection of blog posts that should aid your understanding of Omnichannel. In this post I will concentrate on how to route record to agents.

Note:
Whilst I have created this blog post connected with my MB 230 exam revision guide this post should prove useful to anyone wishing to setup record routing within Microsoft's Omnichannel for Customer Service.

Often we will use Omnichannel for Customer Service to directly converse with customers via say web chat or SMS messages. But we may also need agents to engage with newly created emails, cases, leads or maybe even custom entities. Imagine a customer creates a high priority case in your web portal it might be important that this case is handled as rapidly as a web chat conversation!

In this blog post I will explain how record routing operates by creating an example setup. In my example I will route emails from a specific email account into Omnichannel for Customer Service. To support this I have already create a shared mailbox called "omnichannel@<<mydomain>>.com". This mailbox has been tested successfully and is already working with Dynamics 365. Meaning incoming emails are appearing on a mail queue as expected. But those emails are not being routed to the correct agents, yet. In my example I only enabled this mailbox for incoming email. Which I guess may actually be a typical mail box setup for this kind of scenario.

I guess before diving in I should stress that this is just one example scenario! You can route any record type. In fact I already route cases and leads to agents. I've also created a custom activity called "Offline Message" that I route to my agents. You can see this below … as I have opened my Omnichannel admin center. Under the record routing option you can see all of the existing record types being routed. (Obviously if you are about to define your first record type your list may be blank!)

There are several steps involved in configuring record routing. In the remainder of this post I will describe each step in detail. The steps are listed below;

  1. Create Record Type
  2. Create Workstream
  3. Create intake rules
  4. Create work classification (optional)
  5. Create Routing rules
  6. Configure work distribution settings
  7. Create a Power Automate Flow to route the entity

Step One – Create Record Type

In this first step we will simply define the record type to be routed. Below you can see that I have selected "+ Add" and then chosen my record type. In my example the record type is "Email". You could select case or any record type as required.

Once completed you can continue to create the details of the workstream and any intake rules needed when routing this entity.

Step Two - Create Workstream

Tip: Create a workstream before defining intake rule!

As with all "conversation" types in Omnichannel for Customer Service we need to create a workstream that will define how our sessions will "behave".

Below you can see that after my record type has been defined I need to add a workstream and potentially an intake rule.

When I create my workstream I give it a name. The workstream type is "Record" and then I pick which record type applies to this workstream. In my example that is "Email". At this point I could opt to have a pick or push distribution mode. For this exampled I selected "Push". Meaning messages will be routed (pushed) to specific agents in my queue. And because of that the message will popup for the next available agent.

An alternative approach is the pick distribution method. With pick the conversations are added to the queue but are not assigned to a specific agent. Meaning any agent in the queue can pick the messages manually.

Step Three - Create intake rules

The idea of the intake rules is to "filter" which records are going to be routed. I could leave this blank and route all new records to my agents.

I would use an intake rule if I only want to route high priority cases. Or in my example I only want to route emails that were received on my shared mailbox.

Below you can see that I gave my intake rule a name. I then added a condition to decide which emails would be applicable. In my example I selected my receiving mailbox. (Obviously, if you are following these steps then you will no doubt have a different name for your mailbox!)

Below you can see that I ended up with an intake which would only route emails that were received on my shared mailbox.

Step Four - Create work classification (optional)

Work classification is an optional step! But in the interest of giving a full example I did define a basic approach to work classification. The idea here is classify the "conversations" (or work items) and then route to agents using that classification. For example, I might want to only route to agents that have specific skills.

Below you can see that I selected "Create new".

I can now define the logic I want to apply to work classification. In my simple example I have opted to use a manual classification approach. I've only defined one ruleset. But you could have multiple rulesets that have different conditions or use machine learning to intelligently route your records.

The setup of machine learning involves creating and training a machine learning model. (That can involve creating quite a lot of sample data!!) I describe using machine learning to route entities in this post. In my example of routing emails machine learning could be a really interesting concept. As my model could "read" the email description and by establishing the intent of the email assign suitable skills suggest using artificial intelligence.

Below you can see that I stuck with a simple approach … I gave my ruleset a name and selected manual.

Once opened I could use the "+ Create rule" option to create my classification rule.

Below you can see that I didn't add a condition. You need to be aware that this means only this one rule will be considered. (Which was fine for my example!) Each classification has an output, of the skill we have classified the email with. In my example I'd created a skill called "Omnichannel". Obviously you'd probably create a more meaningful skill.

Imagine you have different email accounts for different types of customer queries. I hope you can see that we could extend this logic to apply different skills to different records, probably based on some condition.

Step Five - Create Routing rules

Next we define which queue the record will be routed to. Again my example is pretty simple … as I'm going to opt to route all records to the same queue. But I hope you can see that we could conditionally route to different queues.

Tip: If you skip this step, all emails would be routed to your default entity queue.

Below you can see that I have given my routing ruleset a name and then selected "Create".

I can then use then "+ Create rule" option to create my routing rule.

In my example I simply gave my rule a name and selected my queue. In my simple setup I have just the one queue called "Entity Queue". But you could have multiple entity queues, then you'd need several rules that conditionally route to the required queue.

Step Six - Configure work distribution settings

When you create a work stream you will get a default set of work distribution settings. In some circumstances using the defaults will be fine! But you should review these settings.

Some options to consider include;

  • Capacity – this is the amount of agent capacity that will be consumed when assigned work items in this workstream. The default is typically "30". In my example I opted to reduce this value as I felt my agent could handle more emails concurrently than say web chat conversations.
  • Allowed presences – I will only route records to agents that have a presence of Available or Busy. (Tip: Busy means they are working on something but they may still have capacity!)
  • Default skill matching algorithm – I have classified my record using a skill. This means I then have two options on how to use this data when distributing work. My options being exact match or closest match. Exact match means the agent must have the skill listed in the classification. Closest match would first look for an agent with the required skill or skills. But if none are available an agent with the closest match would be selected. (Closest match is useful when you want to always route to an agent!)


Step Seven - Create a Power Automate Flow to route the entity

You may also need to create a Cloud Flow!

If the record type you are routing is "case" then any new cases will be automatically considered for routing within Omnichannel. But if you are trying to route other system or custom tables then you need to trigger routing when records are created. We do this by creating a Power Automate flow that will start the routing process.

This post from Microsoft documents the detailed process for creating the required flow …. Route records automatically using custom flow | Microsoft Docs

I have shown the steps from my Cloud Flow below. You can see that it is triggered when ever a new email is created.

I then have just one step which performs an "unbound action". This runs an action called "msdyn _ApplyRoutingRuleEntityRecord". (Catchy name!) Having selected the action I define the target. This is the table and record to be routed. So "emails(<<my record to be routed>>)".

Testing / End Result

Having carefully completed all of my setup I could now test the end results. I admit there are quite a few steps in this process and it is important to carefully check each one before you try and complete a test. As a problem at any stage could result in your record not being routed.

Tip: If you are using record routing on emails you may need to be mindful that it can take around 15 minutes for a new email to show within Dynamics 365. In my experience this does not cause any issues in the real-world but whilst testing you may need to be patient!

When an email arrives in Dynamics 365 it is routed to my agent. You can see below that the agent gets a notification that a new email have arrived. (I have my Customer Service Workspace app open but agents could also use the multi-session experience in the Omnichannel for Customer Service app.)

When the agent opens the item a session will start. This allows them to review the details of the email and maybe use the "convert to" option to create a case, opporuntity or lead as required.

I hope this example of creating record routing for an email entity will have helped you understand the concepts connected with record routing within Omnichannel for Customer Service. Enjoy!