When a support case arrives in Dynamics 365 Customer Service, getting it to the right agent within seconds determines whether your customer gets resolution or frustration. Most organizations start with simple queue-based routing, quickly discovering that hardcoded queue assignments become brittle once you add channels, teams, skill requirements, or global operations. At that point, you need unified routing with workstream configuration that actually handles complexity without becoming unmaintainable.
This article covers the technical architecture of omnichannel work stream routing in Dynamics 365 Customer Service, shows how to configure work streams for records across multiple channels, explains the classification and assignment stages that drive intelligent routing decisions, and walks through patterns that solution architects and developers use when implementing context-based routing in production environments without creating technical debt.
The Architecture Behind Omnichannel Routing
Unified routing in D365 Customer Service operates in two stages. The classification stage runs when a work item arrives, using rules and machine learning models to add metadata that describes the work. A rule might examine the case priority and customer category to assign a skill requirement; an ML model might predict the appropriate skill based on the case description. The second stage, assignment, takes that classified work item and matches it against available agents, considering not just their assigned skills, but their current workload across all channels. The system maintains a unified view of agent utilization, so one agent’s engagement on a chat doesn’t leave them overloaded with email afterwards.
This two-stage model is what separates unified routing from older queue-based systems. In legacy omnichannel configurations, you defined queues, manually assigned agents to queues, and set work distribution to push or pick mode. That works fine for single-channel, single-team scenarios. But when you add inbound email, web chat, social messaging, and different service teams with overlapping skill sets, static queue assignment becomes either overly rigid or so granular that you end up maintaining hundreds of queues and constantly reassigning agents as the business changes.
Unified routing inverts that: instead of assigning agents to queues, you define the work characteristics (via classification rules) and let the system find matching agents in real time. This shift is fundamental, and it changes how you think about routing configuration at nearly every level.
Work Streams as the Routing Backbone
A work stream in D365 Customer Service is the configuration object that connects a specific entity type (like Case) to the routing and assignment system. A work stream defines the entity being routed (Case, Request, or custom entity), the channel through which it arrives (Entity Records channel for server-side routing), the work distribution mode (Push for automatic agent assignment, Pick for agent-initiated pull), capacity units required per work item, and allowed agent statuses that can receive work.
When you create a work stream, you are not assigning agents to it. Instead, you are saying: “Work items of this type coming through this channel should go through unified routing.” The actual assignment happens in real time based on the agent’s skills, availability, and current workload.
Here is where many implementations stumble. In the old omnichannel system, creating a workstream for Entity Records meant you manually mapped which users or teams belonged to that work stream’s queue. That felt straightforward in simple scenarios. In unified routing, no such manual queue assignment exists. Instead, you configure routing rules and assignment strategies at the organization level, and the system applies them to all work streams that use unified routing. This design reduces configuration overhead once you set it up correctly, but it requires a shift in mental model.
Classification: Adding Context to Incoming Work
When a case is created or modified, classification rules run to determine what skills, urgency, or priority level should be attached to that work item. These rules examine entity attributes (the case description, priority field, customer account), related entity data (account industry, support contract tier), or call AI-powered ML models (Intelligent Skill Finder) to predict required skills.
A practical example: a case arrives with priority set to High. A classification rule checks the customer’s account industry and current support contract. If the industry is healthcare and the contract includes 24-hour SLA, the rule adds a “Healthcare Compliance” skill requirement and marks the work as urgent. Another rule checks the case description text; if it mentions “payment” or “billing,” it adds a “Billing” skill. These classifications happen within milliseconds, before assignment even begins.
The key architectural point is that classification is deterministic and idempotent. A rule either matches or does not. If you update the rule logic, you can re-classify existing cases to test whether the new logic works better. This is very different from hard-coding assignment logic in workflows, where you have to remember to update every workflow when business rules change.
Assignment Strategies: Matching Work to Agents
Once a work item is classified, the assignment stage searches for the best-suited available agent. Assignment considers skill matching (does the agent have the required skills at the right proficiency level), workload (how many other active work items is the agent currently engaged with), channel capacity (if the agent is handling multiple channels, does adding this work item exceed their defined capacity), and presence (is the agent in an allowed status like available or ready, or in a status that cannot receive new work like away or offline).
The system evaluates these criteria in real time and assigns the highest-scored matching agent. If no agent is available, the work item enters a queue waiting for the next agent to become available.
This is where context-based routing delivers its practical value. Imagine a chat case that has high complexity (from classification). The system prefers an agent with a “Complex Issues” skill, but if none are available, it can fall back to an agent with a “Customer Service” skill who has demonstrated high case resolution rates via historical performance data (available through metrics integrations). The configuration defines these preference tiers without requiring custom code or workflow logic.
Configuring Work Streams for Records
For a work stream that routes Case records through omnichannel, the configuration steps are straightforward. First, ensure the Case entity is enabled for routing in the Customer Service admin center. Create a new work stream, select “Entity Records” as the channel type, and select “Case” as the entity. Set the work distribution mode (Push or Pick). Push means the system automatically assigns work to an available agent. Pick means cases land in a queue, and agents pull work themselves.
Define capacity units. If your agents handle one case at a time, set capacity to 1. If an agent can work on two simultaneous cases plus a chat session, define capacity so the system knows when they are at their limit. Specify which work streams should use unified routing (in the admin center, associate the work stream with unified routing configuration, not legacy omnichannel routing).
The configuration itself is straightforward. The complexity lives in the classification rules and assignment strategies, not in the work stream definition.
Common Implementation Patterns and Pitfalls
Pattern 1: Multi-entity Routing. Organizations often need to route different entity types (Cases, Requests, Leads) through the same pool of agents. Create separate work streams for each entity type, but use overlapping skill definitions so the assignment system can move work between entity types based on agent capability and availability. Test this thoroughly; if an agent lacks a skill required for one entity type but not others, ensure the assignment logic handles that gracefully.
Pattern 2: Geographic and Timezone-Based Routing. Use classification rules to identify the customer’s region and add location-based skills to the work item. Assignment then prefers agents whose operating hours match the customer’s timezone. This avoids late-night escalations and customer wait times without writing a single custom workflow.
Pitfall 1: Over-granular Skills. Define skills at the level that actually matters for assignment. Having 50 skills makes ML-based skill prediction unreliable and makes manual assignment configuration brittle. Instead, organize skills into categories (Product A, Product B, Product C) and use a smaller number of proficiency levels (1, 2, 3) rather than having Product A Level 1, Product A Level 2, Product B Expert, and so on.
Pitfall 2: Ignoring Workload in Assignment. If you set up skills-based matching but don’t configure capacity rules, the system can overload certain high-skilled agents while others remain idle. Always define capacity per agent or agent group, and test the assignment behavior under load before going live.
Performance Considerations
Unified routing processes classification and assignment synchronously for Cases created via the UI or API. If your organization creates cases in bulk via integration, ensure your integration service handles the timing correctly. Bulk case creation can spike router CPU usage; consider staging bulk cases in a queue and releasing them over time if you see performance degradation.
The Intelligent Skill Finder ML model, if enabled, adds latency to classification. For most cases, this is negligible (under 500ms). However, in high-volume environments (over 500 cases per minute), monitor classifier latency and consider whether you can pre-classify high-volume work via upstream system configuration instead of relying solely on ML.
Bringing It Together
Work stream routing in unified Dynamics 365 Customer Service shifts routing logic from hardcoded queues and workflows to a declarative, rule-based configuration that responds to real-time agent availability and skill matching. The architectural advantage is significant: adding a new team, channel, or skill requirement no longer requires touching case routing logic. The configuration challenge is ensuring your classification rules and assignment strategies actually reflect how work should flow in your organization.
The path forward is to prototype your classification rules against real case data, monitor which rules fire most often and whether they drive better assignment outcomes, and adjust capacity and skill definitions based on actual agent performance. This iterative approach, combined with the technical flexibility that unified routing provides, enables customer service operations that scale without collapsing into overwhelming complexity.
#OmnichannelRouting #DynamicsCustomerService #WorkStreamConfiguration #RoutingRules #SkillsBasedRouting #D365Development