Dynamics 365 Unified Routing - Simply Explained
Key Takeaways
- Dynamics 365 Unified Routing acts as an intelligent front desk, automatically distributing incoming customer service work across multiple channels to the most appropriate agent.
- The routing process is split into two primary phases: classification, which determines what the request needs and tags it with priority and skills, and assignment, which matches those requirements to available agents.
- Basic shared queues often fail as organizations grow because they rely on first-come, first-served logic, leading to bottlenecks and unnecessary handoffs.
- Key building blocks like workstreams, queues, skills, capacity profiles, and presence work together to ensure requests reach the right person based on live availability and workload rather than just the next name on a list.
- Organizations can choose between push assignment for automated, steady distribution in busy desks and pick assignment to give complex technical teams more control over the requests they accept.
When a customer sends a chat message, email, phone request, or support case, they usually expect one thing: the right person should help them as quickly as possible. But customer service becomes complicated as organizations grow. A shared inbox that worked perfectly for five agents can quickly turn into a bottleneck when hundreds of requests arrive through multiple channels, in different languages, with different priorities, and requiring different technical skills. In this episode of Microsoft Knowledge Nuggets on M365 FM, Mirko Peters explains Microsoft Dynamics 365 Unified Routing in plain English. We explore how Unified Routing classifies incoming customer requests, determines priority, identifies required skills, considers agent availability and workload, and then routes the work to the most appropriate person. We also explain workstreams, queues, skills, capacity profiles, presence, push assignment, pick assignment, machine learning, fallback queues, and Copilot Service workspace.
WHAT IS DYNAMICS 365 UNIFIED ROUTING?
Dynamics 365 Unified Routing is an intelligent routing capability designed to automatically distribute incoming customer service work to appropriate agents. Think of it as a smart front desk. Imagine a large office building where visitors arrive with completely different needs. One person needs accounting. Another needs technical support. Another speaks Spanish and needs someone who can communicate with them. Another has an urgent appointment. A good receptionist does not simply point everybody toward the same waiting room. They understand what each visitor needs and direct them toward the right person. Unified Routing performs a similar function for customer service requests. Instead of simply asking "Which agent is next?", the system can consider what the customer needs, who has the necessary skills, who is available, how much work each agent already has, and how urgently the request should be handled.
WHY BASIC CUSTOMER SERVICE QUEUES STOP WORKING
Imagine a small customer service department with five employees. Customers send emails to one shared support address. Every email enters the same queue. When an agent finishes their current task, they take the next request. For a small organization with one product, one language, and relatively few requests, this can work perfectly well. Then the organization grows. Customers begin contacting support through email, live chat, voice, messaging, web forms, and case records. Some customers have billing questions. Others need technical assistance. Some require support in another language. Some have routine questions. Others have critical problems affecting their business. Suddenly, the shared queue looks less like an organized support process and more like a pile of papers sitting on somebody's desk.
THE PROBLEM WITH FIRST-COME, FIRST-SERVED ROUTING
Traditional queues frequently focus on when a request arrived. But arrival time is only one factor. Imagine an experienced technical specialist spending an hour answering basic password questions. Meanwhile, a customer with a serious technical problem waits because nobody noticed that their case requires specialist knowledge. Eventually, another agent opens the case, realizes they cannot solve it, and transfers it. The customer waits again. The organization creates additional work. The specialist eventually receives the request anyway. Unified Routing attempts to reduce these unnecessary handoffs by considering the requirements of the request before assigning it. The goal is to get closer to: Right customer request → right team → right agent → right time.
BASIC ROUTING VS UNIFIED ROUTING
Basic routing can already provide useful structure. An organization might create a simple rule: Billing cases go to the billing queue. Technical cases go to the support queue. For straightforward customer service environments, that may be sufficient. But a queue answers only part of the routing question. It tells the system where the request should wait. It does not necessarily determine which person inside that queue has the appropriate expertise, who is currently available, who already has several active conversations, or whether another request should receive higher priority. Unified Routing addresses this larger assignment problem.
ONE ROUTING APPROACH ACROSS CUSTOMER SERVICE CHANNELS
One of the important ideas behind Unified Routing is applying a common routing approach across different types of customer work. A live chat and an email are obviously different interactions. A telephone call has different timing requirements from a case created through a web form. But they share the same fundamental routing problem: Who should handle this request? Unified Routing can evaluate incoming work according to the organization's configured rules and requirements. The channel becomes one part of the decision rather than requiring an entirely disconnected routing philosophy for every customer interaction.
SKILLS-BASED ROUTING
Skills are one of the most important concepts in Unified Routing. A skill represents something an agent knows how to handle. That might be: A language. A particular product. A technical area. A customer service specialization. A business function. A support level. Incoming work can also receive required skills. Dynamics 365 can then match the requirements of the customer request with the skills associated with available agents.
A SIMPLE SKILLS-BASED ROUTING EXAMPLE
Imagine two agents. Maria understands the company's advanced product line and speaks Spanish. David specializes in account questions and currently has capacity for another email. A Spanish-language request about an advanced technical problem should not automatically go to David simply because he happens to be the next available person. The work requires Spanish and advanced product knowledge. Maria is therefore a much stronger match when she is available and has sufficient capacity. This illustrates the fundamental difference between basic distribution and intelligent routing. Availability alone does not necessarily make somebody the right agent.
THE TWO DECISIONS BEHIND UNIFIED ROUTING
Unified Routing essentially performs two connected operations. First, it determines what the incoming request needs. Then it determines who should receive it. Microsoft's routing process can therefore be understood as: Classification → Assignment Classification adds useful information to the work item. Assignment compares those requirements with available agents. Keeping these two stages separate makes the overall routing process easier to understand.
WHAT IS CLASSIFICATION?
Imagine an email entering Dynamics 365. Initially, it may contain a customer name, subject line, message, and other basic information. That alone may not tell the routing system enough. Is this a billing problem? A product failure? An account question? Which language does the customer require? Does the customer have premium support? Does the case require specialist knowledge? How urgent is the problem? Classification adds the information required to answer those questions. It turns a relatively vague customer request into structured work that the routing system can understand.
CLASSIFICATION RULES
Organizations can configure rules that examine information associated with incoming work. For example, a rule might determine that a customer has a premium support agreement and therefore assign a higher priority. Another rule could inspect the case category and require a billing skill. Another could identify the customer's language and add that language as a routing requirement. The important point is that these decisions become repeatable. Instead of every agent manually deciding how a request should be categorized, the routing configuration applies the organization's service rules consistently.
MACHINE LEARNING AND ROUTING
Rules work particularly well when customer information is structured and predictable. But customers do not always describe the same problem using the same words. One customer might say: "My device won't start." Another writes: "The screen stays black." Another says: "I can't turn it on." These sentences may describe the same underlying problem. Creating manual rules for every possible variation quickly becomes difficult. The supplied episode explains that machine-learning-based capabilities can help predict the skills required for a request by examining patterns in customer text. Instead of creating a separate rule for every phrase, a model can help determine whether a request appears to require product expertise, billing knowledge, or another support skill.
YOU DO NOT ALWAYS NEED MACHINE LEARNING
More intelligence does not automatically mean better routing. A small customer service team with clear case categories may be perfectly successful using straightforward rules. Machine learning becomes more relevant when volumes increase, customer descriptions vary significantly, and maintaining manual routing rules becomes increasingly difficult. The routing architecture should match the complexity of the actual service operation. Organizations should not create an AI problem where a simple business rule already solves the requirement.
PRIORITY IS DIFFERENT FROM SKILLS Skills and priority answer two different questions. Skills ask: Who can solve this? Priority asks: How quickly should we deal with it? A routine request may safely wait behind a serious service disruption. A customer with a premium support agreement may require a faster response. An urgent operational problem may need to move ahead of several normal requests even when those requests arrived earlier. Unified Routing can use classification information to establish priority before an agent receives the work.
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
🚀 Want to be part of m365.fm?
Then stop just listening… and start showing up.
👉 Connect with me on LinkedIn and let’s make something happen:
- 🎙️ Be a podcast guest and share your story
- 🎧 Host your own episode (yes, seriously)
- 💡 Pitch topics the community actually wants to hear
- 🌍 Build your personal brand in the Microsoft 365 space
This isn’t just a podcast — it’s a platform for people who take action.
🔥 Most people wait. The best ones don’t.
👉 Connect with me on LinkedIn and send me a message:
"I want in"
Let’s build something awesome 👊
Frequently Asked Questions
What is Dynamics 365 Unified Routing?
Dynamics 365 Unified Routing is an intelligent capability designed to automatically distribute incoming customer service work—such as chats, emails, and phone calls—to the most appropriate agents based on skills, priority, and availability.
How do classification and assignment work together in Unified Routing?
Classification first analyzes the incoming request to add structured metadata like required skills, language, and priority. Assignment then compares those specific requirements against available agents, their skill levels, and their current workload to find the best match.
What is the difference between push assignment and pick assignment?
Push assignment automatically sends a new work item directly to an eligible agent's workspace, whereas pick assignment allows qualified agents to view items waiting in a queue and choose which ones to accept.
Why are capacity profiles important in Dynamics 365 routing?
Capacity profiles set the amount and type of concurrent work an agent can handle, preventing the system from assigning new requests to available agents who are already at their maximum workload.
00:00:00,000 --> 00:00:04,680
When a customer sends a chat, email, phone request or case record, they need help now,
2
00:00:04,680 --> 00:00:08,320
but their request can easily land in a shared queue where it waits for the right person
3
00:00:08,320 --> 00:00:09,480
to notice it.
4
00:00:09,480 --> 00:00:12,120
Think of a busy office building with one front desk.
5
00:00:12,120 --> 00:00:15,240
Visitors arrive with different needs, and the receptionist has to send each one to the
6
00:00:15,240 --> 00:00:18,120
right room, not just point them toward a crowded waiting area.
7
00:00:18,120 --> 00:00:23,840
EOTM-M, Mirko Peters from M365FM, and this knowledge nugget puts Dynamics 365 unified
8
00:00:23,840 --> 00:00:25,520
rooting into plain English.
9
00:00:25,520 --> 00:00:29,780
You will see how it sorts incoming work, chooses who should handle it, and uses workstreams
10
00:00:29,780 --> 00:00:33,220
queues, skills and capacity behind the scenes.
11
00:00:33,220 --> 00:00:35,260
Why basic queues stop working?
12
00:00:35,260 --> 00:00:39,860
Imagine a small support team with five people, where customers email one shared address,
13
00:00:39,860 --> 00:00:43,780
every case enters one queue, and an agent picks the next item when they finish their current
14
00:00:43,780 --> 00:00:44,780
work.
15
00:00:44,780 --> 00:00:48,060
For a small team with one product and one language, that works well enough.
16
00:00:48,060 --> 00:00:49,220
Then the company grows.
17
00:00:49,220 --> 00:00:53,060
Now customers contact the team through email, chat, voice and messaging, some ask about
18
00:00:53,060 --> 00:00:57,740
billing, others report a product problem, and a few need help in another language.
19
00:00:57,740 --> 00:01:01,500
Some customers have urgent issues, and some cases can wait until tomorrow.
20
00:01:01,500 --> 00:01:06,220
One shared queue starts to look less like a helpful inbox, and more like a pile of papers on
21
00:01:06,220 --> 00:01:07,220
a desk.
22
00:01:07,220 --> 00:01:08,540
Here are our teams what happens.
23
00:01:08,540 --> 00:01:12,820
An experienced product specialist might spend an hour answering simple password questions.
24
00:01:12,820 --> 00:01:17,180
Meanwhile, a customer with a serious product problem waits, because nobody notice the case,
25
00:01:17,180 --> 00:01:20,580
or because the agent who first opens it needs to pass it to someone else.
26
00:01:20,580 --> 00:01:24,660
That handoff creates extra work for the team, and extra waiting for the customer.
27
00:01:24,660 --> 00:01:27,900
Public routing can improve this a little by letting you create a rule that sends billing
28
00:01:27,900 --> 00:01:31,140
cases to a billing queue or product cases to a support queue.
29
00:01:31,140 --> 00:01:35,180
That gives work some structure, and for simple service setups it may be all you need.
30
00:01:35,180 --> 00:01:38,980
But a queue only answers part of the question, it can tell you where a request should wait,
31
00:01:38,980 --> 00:01:42,780
but it doesn't always decide which available person has the right knowledge, who already
32
00:01:42,780 --> 00:01:46,860
handles several chats, or whether a more urgent request should come first.
33
00:01:46,860 --> 00:01:49,260
So unified routing tackles the larger problem.
34
00:01:49,260 --> 00:01:52,660
It uses one routing approach across different kinds of customer work.
35
00:01:52,660 --> 00:01:56,860
A chat and an email don't need completely separate ways of finding the right agent.
36
00:01:56,860 --> 00:02:00,820
Instead, the system can look at what the request needs, then consider the people who can take
37
00:02:00,820 --> 00:02:01,820
it.
38
00:02:01,820 --> 00:02:04,940
That can include in agent skills, whether they're available, how much work they already
39
00:02:04,940 --> 00:02:07,340
carry, and how urgent the request is.
40
00:02:07,340 --> 00:02:08,340
Picture two agents.
41
00:02:08,340 --> 00:02:12,460
Maria knows the company out, TM's Advanced Product Line, and speaks Spanish.
42
00:02:12,460 --> 00:02:15,380
David handles account questions and has room for another email.
43
00:02:15,380 --> 00:02:18,980
A Spanish email about an advanced product issue shouldn't land with David just because
44
00:02:18,980 --> 00:02:20,980
he happens to be next in a list.
45
00:02:20,980 --> 00:02:25,460
unified routing can direct that request toward Maria when she out to TM is available and
46
00:02:25,460 --> 00:02:26,540
has room for it.
47
00:02:26,540 --> 00:02:30,380
If she can't take it, the routing rules follow the path your service team has planned instead
48
00:02:30,380 --> 00:02:31,940
of leaving the request stranded.
49
00:02:31,940 --> 00:02:35,060
This doesn't replace the people who decide how customer service should work.
50
00:02:35,060 --> 00:02:39,220
Your service leaders still decide which customers need faster help, what skills matter, how
51
00:02:39,220 --> 00:02:43,660
many chats an agent can manage, and where work should go when nobody matches.
52
00:02:43,660 --> 00:02:46,980
Unified routing takes those decisions and applies them the same way each time.
53
00:02:46,980 --> 00:02:49,780
So what does it actually do when a new request arrives?
54
00:02:49,780 --> 00:02:51,540
It makes two connected decisions.
55
00:02:51,540 --> 00:02:55,140
First, it works out what the request needs, then it finds the right place and person for
56
00:02:55,140 --> 00:02:56,540
that work.
57
00:02:56,540 --> 00:02:59,620
The two decisions behind every assignment.
58
00:02:59,620 --> 00:03:03,540
So unified routing does two things, and it does them in a specific order.
59
00:03:03,540 --> 00:03:06,580
First, it looks at incoming work and classifies it.
60
00:03:06,580 --> 00:03:09,660
Then it assigns that work to a person.
61
00:03:09,660 --> 00:03:12,660
Classification is really just a system checking a new request and tagging it with the details
62
00:03:12,660 --> 00:03:14,220
needed to root it correctly.
63
00:03:14,220 --> 00:03:16,260
Imagine an email comes in from a customer.
64
00:03:16,260 --> 00:03:21,300
Right now it only has a subject line, a message, and the customer EOTM is name.
65
00:03:21,300 --> 00:03:23,260
That does not might tell your service team enough.
66
00:03:23,260 --> 00:03:27,620
Is this a billing question, a broken product, a delivery problem, an account issue?
67
00:03:27,620 --> 00:03:30,660
The classification step adds useful labels to answer those questions.
68
00:03:30,660 --> 00:03:33,660
It can figure out where the request came from, which product the customer mentioned, what
69
00:03:33,660 --> 00:03:37,180
type of customer they are, the language they used, and what kind of help they need.
70
00:03:37,180 --> 00:03:41,540
Those labels turn a vague request into work that the routing system can understand and act
71
00:03:41,540 --> 00:03:42,540
on.
72
00:03:42,540 --> 00:03:44,340
Most of the time you set this up with rules.
73
00:03:44,340 --> 00:03:48,500
For example, a rule might look at the customer record and see they have a premium support plan.
74
00:03:48,500 --> 00:03:51,940
Another rule could check the case category and add a required skill like billing or technical
75
00:03:51,940 --> 00:03:52,940
support.
76
00:03:52,940 --> 00:03:57,540
Or a rule could notice the request arrived in Spanish and attach a language requirement.
77
00:03:57,540 --> 00:04:00,620
The system does no a timid read every email like a person would.
78
00:04:00,620 --> 00:04:02,940
Instead it checks the conditions your team has set.
79
00:04:02,940 --> 00:04:05,940
If this customer belongs to a certain group, add this priority.
80
00:04:05,940 --> 00:04:09,020
If the case is about this product, require this skill.
81
00:04:09,020 --> 00:04:11,780
If the request came from a certain channel, send it that way.
82
00:04:11,780 --> 00:04:14,300
That gives you clear, repeatable results every time.
83
00:04:14,300 --> 00:04:17,780
But rules can get long when customers describe the same problem in different ways.
84
00:04:17,780 --> 00:04:20,020
One person writes only device won't start.
85
00:04:20,020 --> 00:04:22,620
Our another writes our the screen stays black.
86
00:04:22,620 --> 00:04:24,820
Our third says, oh, I can't turn it on.
87
00:04:24,820 --> 00:04:27,660
Your machine learning can handle that kind of pattern much better.
88
00:04:27,660 --> 00:04:31,260
Microsoft, our S&T MMO's routing tools can use machine learning models to predict the
89
00:04:31,260 --> 00:04:32,820
skills the request needs.
90
00:04:32,820 --> 00:04:36,620
Instead of writing a separate rule for every phrase, a model can review the text and
91
00:04:36,620 --> 00:04:41,780
guess whether the request needs a product specialist, a billing expert, or another type of support.
92
00:04:41,780 --> 00:04:44,500
You don't know what team need machine learning for every setup though.
93
00:04:44,500 --> 00:04:48,620
A small team with clear case categories can get everything it needs from simple rules.
94
00:04:48,620 --> 00:04:54,620
Machine learning becomes useful when volume grows, customer wording varies a lot, and manual rules start getting hard to manage.
95
00:04:54,620 --> 00:04:57,260
Classification can also set the priority of the work.
96
00:04:57,260 --> 00:04:59,540
Priority answers a different question from skills.
97
00:04:59,540 --> 00:05:01,700
Skills ask, oh, who can solve this?
98
00:05:01,700 --> 00:05:05,260
A/O priority asks, oh, how soon should we deal with it?
99
00:05:05,260 --> 00:05:08,580
A/O, a routine request might wait behind a serious service problem.
100
00:05:08,580 --> 00:05:12,420
A case from a customer with a higher support agreement might need faster attention.
101
00:05:12,420 --> 00:05:17,860
Unified routing can use the details from classification to sort that work before an agent ever sees it.
102
00:05:17,860 --> 00:05:20,780
So classification gives the request a clear set of labels.
103
00:05:20,780 --> 00:05:25,100
It tells the system what the work is, what it needs, and how urgently it should move.
104
00:05:25,100 --> 00:05:26,740
Then assignment begins.
105
00:05:26,740 --> 00:05:31,460
Assignment looks at the requirements on the work item and compares them to the people who could handle it.
106
00:05:31,460 --> 00:05:37,420
The system checks agent skills, their skill level where that applies, their Q membership, their availability, and their current workload.
107
00:05:37,420 --> 00:05:40,100
That last part matters more than people often think.
108
00:05:40,100 --> 00:05:45,180
An agent might have the right product knowledge, but they could already be handling as much work as their capacity allows.
109
00:05:45,180 --> 00:05:49,620
Another agent might have the same skill, show as available, and have room for a new request.
110
00:05:49,620 --> 00:05:53,100
The system can choose the person who fits the request and can actually take it right now.
111
00:05:53,100 --> 00:05:55,660
This is what Microsoft means by the best suited agent.
112
00:05:55,660 --> 00:05:58,380
It does not meant just mean the next name in a list.
113
00:05:58,380 --> 00:06:01,940
It means the person who matches the work requirements under the rules you chose.
114
00:06:01,940 --> 00:06:04,620
Sometimes that might be the agent with the lowest current workload.
115
00:06:04,620 --> 00:06:10,340
In another setup, it could be the next qualified available person, depending on the assignment method your team picks.
116
00:06:10,340 --> 00:06:11,900
The presence also feeds into that choice.
117
00:06:11,900 --> 00:06:15,940
If someone is offline or way or busy at their limit, rooting should look elsewhere.
118
00:06:15,940 --> 00:06:21,060
Without that live view of availability and workload, an assignment system can send work to people who can't respond.
119
00:06:21,060 --> 00:06:22,660
So the process follows a simple path.
120
00:06:22,660 --> 00:06:23,540
The request arrives.
121
00:06:23,540 --> 00:06:26,060
Classification adds the information needed to handle it.
122
00:06:26,060 --> 00:06:27,900
Priority places it in the right order.
123
00:06:27,900 --> 00:06:31,020
Assignment finds a suitable available agent with enough capacity.
124
00:06:31,020 --> 00:06:33,460
The next question is where all those instructions live.
125
00:06:33,460 --> 00:06:39,580
So answer that we need to look at the building blocks that shape rooting inside Dynamics 365.
126
00:06:39,580 --> 00:06:40,660
The building blocks.
127
00:06:40,660 --> 00:06:44,260
Workstreams, queues, skills and capacity.
128
00:06:44,260 --> 00:06:47,500
Those rooting decisions need a home inside Dynamics 365.
129
00:06:47,500 --> 00:06:49,140
The main starting point is a workstream.
130
00:06:49,140 --> 00:06:52,340
Think of a workstream as the front desk for one kind of incoming work.
131
00:06:52,340 --> 00:06:58,660
You might create one for live chat, another for voice calls, another for messaging, and another for case records like emails or web forms.
132
00:06:58,660 --> 00:07:02,700
Each workstream tells Dynamics 365 what to do when that kind of work arrives.
133
00:07:02,700 --> 00:07:05,540
For a record workstream, the incoming item might be a case.
134
00:07:05,540 --> 00:07:08,700
For a chat workstream, ETL attempts a live conversation.
135
00:07:08,700 --> 00:07:11,700
The work looks different, but the basic job stays the same.
136
00:07:11,700 --> 00:07:16,260
Bring the request in, add the right details, and help it reach the right team member.
137
00:07:16,260 --> 00:07:18,540
A workstream contains the rules for that journey.
138
00:07:18,540 --> 00:07:21,780
It can decide which incoming records belong there through intake rules.
139
00:07:21,780 --> 00:07:26,700
It can contain classification rules that add skills, priority, or other details.
140
00:07:26,700 --> 00:07:29,780
It can also include rules that send work toward the correct queue.
141
00:07:29,780 --> 00:07:34,060
To it me, I'll usually choose a fallback queue as well.
142
00:07:34,060 --> 00:07:37,460
That wouldn't be the safe place for work when the normal route cannot automatically find a match.
143
00:07:37,460 --> 00:07:42,980
Maybe no agent currently has the required skill, maybe the team has no timid finish setting up a new product category.
144
00:07:42,980 --> 00:07:49,020
Rather than letting the request disappear into nowhere, Dynamics 365 can send it to a queue where someone can review it.
145
00:07:49,020 --> 00:07:51,740
A workstream also controls how agents receive work.
146
00:07:51,740 --> 00:07:55,740
With push assignment, the system sends a new item directly to an eligible agent.
147
00:07:55,740 --> 00:07:58,300
The agent gets a notification and starts working on it.
148
00:07:58,300 --> 00:08:02,780
This works well when you want the system to keep work moving without agents watching a list all day.
149
00:08:02,780 --> 00:08:04,980
Pick assignment takes a different approach.
150
00:08:04,980 --> 00:08:08,420
Eligible agents see work waiting in a queue and choose which item to take.
151
00:08:08,420 --> 00:08:13,740
That gives agents more control, which can help in teams where people need to judge the work before they accept it.
152
00:08:13,740 --> 00:08:18,260
The workstream helps set that behavior, but your team decides which approach fits the job.
153
00:08:18,260 --> 00:08:21,060
Now, where does work wait before an agent takes it?
154
00:08:21,060 --> 00:08:22,700
That opens where queues come in.
155
00:08:22,700 --> 00:08:25,060
A queue is a waiting area and a team boundary.
156
00:08:25,060 --> 00:08:30,780
It groups work that belongs with a certain part of the service team, like billing, product support or customer onboarding.
157
00:08:30,780 --> 00:08:33,220
Many people treat a queue like the whole routing system.
158
00:08:33,220 --> 00:08:34,700
It is no timid.
159
00:08:34,700 --> 00:08:41,300
A queue can hold work and identify the group responsible for it, but it does no timid contain the full picture by itself.
160
00:08:41,300 --> 00:08:46,260
The routing process still needs to know which person in that group can handle the request right now.
161
00:08:46,260 --> 00:08:51,140
For example, a technical support queue might include 10 agents, only four might know a certain product.
162
00:08:51,140 --> 00:08:56,300
Of those four, perhaps two are away and one already handles the maximum number of chats.
163
00:08:56,300 --> 00:09:01,260
The queue points the request in the right direction, while the other routing details narrow down the right person.
164
00:09:01,260 --> 00:09:03,100
Those details often come from skills.
165
00:09:03,100 --> 00:09:06,740
A skill is a label that describes something an agent knows how to handle.
166
00:09:06,740 --> 00:09:10,980
It might be a language, a product line, a support level, or a business area.
167
00:09:10,980 --> 00:09:15,460
You add skills to agents, you can also add required skills to incoming work.
168
00:09:15,460 --> 00:09:18,420
If a customer writes in German, the request can require German.
169
00:09:18,420 --> 00:09:20,860
If the case concerns advanced network setup,
170
00:09:20,860 --> 00:09:22,660
it can require that product skill.
171
00:09:22,660 --> 00:09:26,700
Dynamics 365 then looks for agents whose own skills match the request.
172
00:09:26,700 --> 00:09:28,260
Skill levels add another layer.
173
00:09:28,260 --> 00:09:30,060
Imagine two people both know a product.
174
00:09:30,060 --> 00:09:34,860
One handles basic questions after training, while the other solves complex technical faults every day.
175
00:09:34,860 --> 00:09:36,820
A simple "oh" work can I find this setting?
176
00:09:36,820 --> 00:09:38,900
A/O question may suit either person.
177
00:09:38,900 --> 00:09:41,820
A serious product issue can require the advanced level.
178
00:09:41,820 --> 00:09:45,340
That keeps simple work from automatically landing with the most experienced person,
179
00:09:45,340 --> 00:09:48,540
while difficult work has a better chance of reaching someone ready for it.
180
00:09:48,540 --> 00:09:53,900
Skills only describe fit though, they do not want them to tell the system whether an agent has room for another task.
181
00:09:53,900 --> 00:09:57,140
That "au" teams the job of capacity profiles.
182
00:09:57,140 --> 00:10:01,820
A capacity profile sets the amount and type of work an agent can handle at one time.
183
00:10:01,820 --> 00:10:04,140
Picture each agent with a limited number of work slots.
184
00:10:04,140 --> 00:10:07,060
A live chat can take one slot, an email may take another.
185
00:10:07,060 --> 00:10:11,500
A voice call can fill the agent totems full attention depending on how your team sets it up.
186
00:10:11,500 --> 00:10:14,820
You might decide that an agent can handle two chats and one email at once.
187
00:10:14,820 --> 00:10:19,100
Another agent might handle one voice call and no additional chats during that call.
188
00:10:19,100 --> 00:10:22,700
A senior agent might handle more concurrent work than someone new to the team,
189
00:10:22,700 --> 00:10:26,740
but only if that matches the way your service team actually works.
190
00:10:26,740 --> 00:10:29,740
Capacity is now too late about pushing more work onto people.
191
00:10:29,740 --> 00:10:33,100
It stops the system from treating every available person as equally free,
192
00:10:33,100 --> 00:10:36,260
an agent who appears online may already be fully occupied.
193
00:10:36,260 --> 00:10:41,300
Without capacity rules, new requests can keep arriving for that person while another qualified agent has room.
194
00:10:41,300 --> 00:10:43,820
Presence fills in the other part of the picture.
195
00:10:43,820 --> 00:10:47,460
Dynamics 365 needs to know whether someone can receive work at that moment.
196
00:10:47,460 --> 00:10:50,620
An agent who is offline away or unavailable should know them.
197
00:10:50,620 --> 00:10:52,340
He'd receive a new customer request.
198
00:10:52,340 --> 00:10:55,820
An agent who is available and still has capacity becomes a possible match.
199
00:10:55,820 --> 00:10:58,380
So these building blocks each handle a different part of the job.
200
00:10:58,380 --> 00:11:01,060
Work streams control the path for a type of work.
201
00:11:01,060 --> 00:11:03,140
Cue's organized responsibility.
202
00:11:03,140 --> 00:11:06,340
Skills describe what the work needs and what agents know.
203
00:11:06,340 --> 00:11:09,580
Capacity and presence show who can take the work now.
204
00:11:09,580 --> 00:11:13,540
Put those pieces together and a customer request can move through a clear set of decisions
205
00:11:13,540 --> 00:11:16,180
instead of relying on somebody to spot it first.
206
00:11:16,180 --> 00:11:19,740
One request from customer message to write agent.
207
00:11:19,740 --> 00:11:23,020
Let's follow one customer request through the system and see how each piece works.
208
00:11:23,020 --> 00:11:25,660
So imagine a customer sends an email in Spanish.
209
00:11:25,660 --> 00:11:27,500
Their company uses an advanced product,
210
00:11:27,500 --> 00:11:29,300
the issue stops part of their work
211
00:11:29,300 --> 00:11:31,980
and their support agreement means it needs quick attention.
212
00:11:31,980 --> 00:11:34,140
At first it's just an email or nothing special.
213
00:11:34,140 --> 00:11:37,260
That email enters Dynamics 365 as a case record
214
00:11:37,260 --> 00:11:40,500
and intakes rule checks whether the record belongs in the right work stream.
215
00:11:40,500 --> 00:11:46,500
In this example, the rule sees it arrived by email and roots it into the email or record work stream for customer support.
216
00:11:46,500 --> 00:11:51,340
Once that work stream takes over, the classification rules look at the details already attached to the case
217
00:11:51,340 --> 00:11:56,980
over the email origin, the customer account, the product listed, the urgency level and the language needed.
218
00:11:56,980 --> 00:12:00,300
Each rule adds information that changes the next decision.
219
00:12:00,300 --> 00:12:04,700
The customer account may identify a premium support plan, so the case gets a higher priority.
220
00:12:04,700 --> 00:12:08,060
The selected product may require an advanced product support skill.
221
00:12:08,060 --> 00:12:11,860
The language field adds Spanish as another required skill.
222
00:12:11,860 --> 00:12:14,940
Here's the thing, nothing has reached an agent yet.
223
00:12:14,940 --> 00:12:20,900
But the request now carries a clear set of needs, high priority, advanced product knowledge and Spanish language support.
224
00:12:20,900 --> 00:12:26,300
That gives Dynamics 365 something specific to match instead of sending a vague email to a general team.
225
00:12:26,300 --> 00:12:31,220
A root to queue rule can then place the case in the queue responsible for that product area.
226
00:12:31,220 --> 00:12:32,620
Notice what the queue does here.
227
00:12:32,620 --> 00:12:37,740
It puts the case with the right service group, but the queue doesn't just hand it to the first person it finds.
228
00:12:37,740 --> 00:12:41,420
The case still needs an agent who meets its requirements and has capacity for it.
229
00:12:41,420 --> 00:12:44,540
So Dynamics 365 looks at the eligible agents in that queue.
230
00:12:44,540 --> 00:12:47,580
Take a team of four agents in the Advanced Product Support queue.
231
00:12:47,580 --> 00:12:49,420
One speaks Spanish but is away.
232
00:12:49,420 --> 00:12:52,020
One is available but only handles basic products.
233
00:12:52,020 --> 00:12:56,860
And the third has the right skills but is already at full capacity with active chats and emails.
234
00:12:56,860 --> 00:13:03,340
The fourth agent, Elena, speaks Spanish, holds the Advanced Product Skill level, is available and has room for one more email.
235
00:13:03,340 --> 00:13:04,780
She becomes the best match.
236
00:13:04,780 --> 00:13:08,700
With Push Assignment, Dynamics 365 sends the case directly to Elena.
237
00:13:08,700 --> 00:13:15,420
She gets the work notification in the co-pilot service workspace, opens the case and starts with the details already gathered during rooting.
238
00:13:15,420 --> 00:13:18,620
Your customer doesn't need to repeat the product issue to a general agent.
239
00:13:18,620 --> 00:13:22,780
And Elena doesn't need to dig through a busy queue guessing which cases to take out.
240
00:13:22,780 --> 00:13:25,580
She receives a request that fits her skills and current workload.
241
00:13:25,580 --> 00:13:27,140
That's Push Assignment in plain English.
242
00:13:27,140 --> 00:13:30,060
The system chooses an eligible person and sends the work to them.
243
00:13:30,060 --> 00:13:31,820
But some teams need a different approach.
244
00:13:31,820 --> 00:13:35,260
Imagine a group of senior technical agents who handle complex cases.
245
00:13:35,260 --> 00:13:38,220
Each case might need a quick review before someone accepts it.
246
00:13:38,220 --> 00:13:44,060
One agent may know a customer's setup well and another may already work on a related case and can spot the issue faster.
247
00:13:44,060 --> 00:13:46,460
For that kind of team, pick Assignment works better.
248
00:13:46,460 --> 00:13:51,100
The rooting process still sends the case to the right queue and identifies which agents qualify.
249
00:13:51,100 --> 00:13:55,980
Instead of pushing it straight to Elena, eligible agents can see the case in the queue and choose to take it.
250
00:13:55,980 --> 00:13:58,700
That doesn't mean the work becomes unstructured again now.
251
00:13:58,700 --> 00:14:02,300
Only the people who meet the rooting requirements see it as work they can pick.
252
00:14:02,300 --> 00:14:05,500
The team keeps the skills, priority and capacity controls.
253
00:14:05,500 --> 00:14:08,540
While agents keep more choice over the order of their own complex work,
254
00:14:08,540 --> 00:14:11,740
whether you choose Push or Pick depends on how your service team works.
255
00:14:11,740 --> 00:14:15,900
Push Assignment fits a busy service desk where speed and steady distribution matter.
256
00:14:15,900 --> 00:14:20,460
Pick Assignment Fits work where the agent needs more control before accepting the next request.
257
00:14:20,460 --> 00:14:23,180
Either way, your customer sees a simpler experience.
258
00:14:23,180 --> 00:14:26,780
Their message reaches someone who can handle it without unnecessary transfers.
259
00:14:26,780 --> 00:14:29,980
The service team spends less time sorting and forwarding cases.
260
00:14:29,980 --> 00:14:35,180
And because Dynamics 365 records the assignment, the case has a clearer owner from the start.
261
00:14:35,180 --> 00:14:38,060
One email involves quite a few decisions behind the scenes,
262
00:14:38,060 --> 00:14:41,740
but the customer only notices one thing, the right person responds.
263
00:14:41,740 --> 00:14:44,780
Planning a rooting model that people can run.
264
00:14:44,780 --> 00:14:49,020
A good rooting setup starts before anyone opens an admin screen.
265
00:14:49,020 --> 00:14:51,100
Start with the service promise you want to keep,
266
00:14:51,100 --> 00:14:54,060
which requests need a faster apply, which ones need a specialist,
267
00:14:54,060 --> 00:14:58,300
which channels need their own path because a live conversation can't wait, like an email can?
268
00:14:58,300 --> 00:15:00,540
Write those answers down in plain language first.
269
00:15:00,540 --> 00:15:04,140
For example, product outages go to the technical team with high priority.
270
00:15:04,140 --> 00:15:08,060
Billing questions go to billing and Spanish messages need a Spanish-speaking agent.
271
00:15:08,060 --> 00:15:11,180
That gives you a clear service policy before you turn it into rules.
272
00:15:11,180 --> 00:15:13,180
Now build a setup in a sensible order.
273
00:15:13,180 --> 00:15:17,260
Create your cues first, because they show which team owns each type of work.
274
00:15:17,260 --> 00:15:19,180
Add the people who belong in those cues,
275
00:15:19,180 --> 00:15:23,820
then define the skills those people actually have and set capacity profiles that match their real workload.
276
00:15:23,820 --> 00:15:26,540
Only after that should you create work streams and routing rules.
277
00:15:26,540 --> 00:15:31,580
Otherwise, you can build rules that point toward teams, skills, or capacity settings that don't exist yet,
278
00:15:31,580 --> 00:15:35,900
making it harder to test and much harder to explain later when somebody needs to fix it.
279
00:15:35,900 --> 00:15:37,100
Keep cues focused.
280
00:15:37,100 --> 00:15:39,180
One giant cue called support can sound simple,
281
00:15:39,180 --> 00:15:42,220
but it soon becomes a place where very different requests pile up together.
282
00:15:42,220 --> 00:15:46,620
A billing question, a product fault, and an onboarding request
283
00:15:46,620 --> 00:15:49,260
may all need different people and different response times.
284
00:15:49,260 --> 00:15:52,060
Use cues that match clear ownership.
285
00:15:52,060 --> 00:15:55,100
That doesn't mean creating a cue for every tiny case type.
286
00:15:55,100 --> 00:15:59,420
It means creating enough separation so that anyone looking at the setup can answer the basic question
287
00:15:59,420 --> 00:16:00,860
which team owns this work.
288
00:16:00,860 --> 00:16:03,180
Classification rules need the same discipline.
289
00:16:03,180 --> 00:16:06,460
Only add a rule when the information changes where the work goes,
290
00:16:06,460 --> 00:16:09,420
who can handle it, or how urgently it needs attention.
291
00:16:09,420 --> 00:16:12,940
If a detail doesn't affect routing, it may not belong in a routing rule.
292
00:16:12,940 --> 00:16:15,020
More rules don't always create better control,
293
00:16:15,020 --> 00:16:16,940
or they can create overlapping conditions,
294
00:16:16,940 --> 00:16:19,820
confusing results, and long troubleshooting sessions,
295
00:16:19,820 --> 00:16:22,380
where nobody knows why a case took a certain path.
296
00:16:22,380 --> 00:16:27,580
Keep each rule easy to explain, then test it against real customer examples.
297
00:16:27,580 --> 00:16:29,660
Always plan for the cases that don't fit.
298
00:16:29,660 --> 00:16:32,620
Maybe a new product appears before its support skill exists.
299
00:16:32,620 --> 00:16:35,020
Maybe every qualified agent reaches full capacity,
300
00:16:35,020 --> 00:16:37,260
or maybe a case arrives with missing information,
301
00:16:37,260 --> 00:16:39,580
so the system can't identify the right route.
302
00:16:39,580 --> 00:16:42,060
Your fallback cue needs an owner who watches it,
303
00:16:42,060 --> 00:16:43,820
reviews work that lands there,
304
00:16:43,820 --> 00:16:46,620
and decides whether the routing setup needs a change.
305
00:16:46,620 --> 00:16:48,940
A fallback cue isn't a place to forget difficult work.
306
00:16:49,820 --> 00:16:52,700
It's an early warning sign that your planned path needs attention.
307
00:16:52,700 --> 00:16:55,100
Testing should include more than the happy path.
308
00:16:55,100 --> 00:16:57,020
Test the case with the right skills available,
309
00:16:57,020 --> 00:16:59,900
then try the same case when every matching agent is unavailable.
310
00:16:59,900 --> 00:17:02,060
Also test what happens when capacity is full,
311
00:17:02,060 --> 00:17:03,340
when a skill is missing,
312
00:17:03,340 --> 00:17:06,220
and when a classification rule can't find the detail it expects,
313
00:17:06,220 --> 00:17:09,420
you want to see where the work goes before a real customer waits there.
314
00:17:09,420 --> 00:17:10,780
One more practical point.
315
00:17:10,780 --> 00:17:13,900
Agents receive work rooted through unified routing
316
00:17:13,900 --> 00:17:15,740
in the co-pilot service workspace,
317
00:17:15,740 --> 00:17:17,900
not through unified service desk,
318
00:17:17,900 --> 00:17:21,180
so that choice affects the workspace your team uses every day.
319
00:17:21,180 --> 00:17:22,620
The setup happens behind the scenes,
320
00:17:22,620 --> 00:17:25,100
but agents and customers feel the result right away.
321
00:17:25,100 --> 00:17:26,940
Clear rules, sensible ownership,
322
00:17:26,940 --> 00:17:29,180
and regular testing keep routing useful,
323
00:17:29,180 --> 00:17:31,180
instead of turning it into another system,
324
00:17:31,180 --> 00:17:32,700
people work around.
325
00:17:32,700 --> 00:17:33,740
Conclusion,
326
00:17:33,740 --> 00:17:35,260
Rooting as a shared front desk.
327
00:17:35,260 --> 00:17:38,300
Think of unified routing as a smart front desk.
328
00:17:38,300 --> 00:17:39,580
It takes your service rules,
329
00:17:39,580 --> 00:17:42,700
and makes sure every request goes exactly where it needs to,
330
00:17:42,700 --> 00:17:44,940
no waiting in a cue hoping someone notices it.
331
00:17:44,940 --> 00:17:48,700
Subscribe to Microsoft Knowledge Nuggets on M365, FM,
332
00:17:48,700 --> 00:17:52,060
and check out the next episode to see how Dynamics 365 services
333
00:17:52,060 --> 00:17:54,940
work together behind your customer support workspace.
