NEIL PARKHURST

A new feature is coming to the Unified Routing feature found in Microsoft’s Dynamics 365 Customer Service app …. It will allow us to route work items to agents based on a contact having one or more preferred resources. I will describe this new feature in this post.

The use case for this feature is that you may have one or more agents that frequently look after a particular agent. Meaning of that customer has a query then it will be best resolved by one of those agents. You can also further define what should happen if those agents aren’t available. You could, for example, then route to any available agent using your normal assignment logic. Or the work item could just “wait” until one of the preferred agents is available.

Note: The preferred resources logic effectively “just” overrides whatever existing assignment logic you have a on queue. Meaning I believe you do also need to ensure the preferred resources are in the target queue.

Setup

You can configure the preferred agent routing option in your customer service admin centre.

Tip:
If you don’t see this option, then you probably need to ensure the 2022 Wave 2 release has been enabled in your environment! In October 2022 that will generally available but currently in August 2022 it needs to be enabled as an early access feature.

Below you can see that I have opened my admin center, and that with the routing option I have a “preferred agent routing” option.

Using the option is simple enough!

First you will need to select the option to enable preferred agent routing.

Next you need to define what will happen if the preferred agent cannot be assigned a work item. (Meaning they are not available!)

I opted to route to the “next best agent based on assignment logic”. As if someone wasn’t available, I didn’t want to keep my customer waiting.

You then use the “+ Add a contact” option to add one or more agents for each contact. Below you can see that if “Bruce Wayne” has an issue that will be routed to me. But if “Alex” called he’d be routed to either me or my cat! (Being a preview feature you can tell I have configured this in a test environment … I don’t really know Batman!)

Testing

Below you can see that I did some tests … and in my customer service workspace. Conversations and cases were routed directly to me if they were from “Bruce Wayne”.

Tip:
See notes below about record routing. As you may have an additional step to configure routing of cases etc.

This was all well and good. But had I proved preferred routing was working as expected! As being a test system, I was the only active user. So how could I prove the routing had actually used my preferred routing setup.

For this I turned to the routing diagnostics option we have in the customer service admin center. (You will find it just above the “Preferred agent routing” option you used earlier!

With my diagnostics running I created a case that would need routing. And afterwards I could see the routing details in the diagnostics. This told me the workstream, queue and agent who were assignment the case. But I needed to drill into the diagnostics record to prove how it was assigned.

Below you can see that in the assignment trace I could get confirmation that the default assignment logic had been ignored and the case had been routed to me based on me being located as the preferred agent.

Entity Records Config

Preferred routing of entity record may need some additional setup!

If you already have Omnichannel for Customer Service installed and want to route cases, emails etc. Then you may have some additional steps to complete. (For each record type you want to route.)

Note: I am assuming this process will only be needed whilst this feature remains in preview!

To find out first you need to navigate a specific URL. If no data is displayed, you probably need to complete some extra config.

YOUROrgURL/api/data/v9.0/msdyn_preferredagentroutedentities

Below you can see that in my instance I began with no code ….

So next I opened my “Customer Service admin center” app and used F12 to open the browser dev tools. I then pasted some code into the console and ran it.

You can find the details of the code to use on the Microsoft site here.

Opening my original URL again now shows the code for my case entity…

Conclusion

So, what do I think!

I didn’t like needing to complete some extra config to enable record routing. But I am confident that is just a “quirk” of this being a preview feature.

But apart from that this feature was easy to setup and worked exactly as expected. And it is yet another option in our growing “routing kit bag”. Unified routing is fast becoming an incredibly flexible routing engine. Nice job Microsoft. Enjoy.