Email as a channel

What it does

Email in Customer Service is not a session-based channel like chat or SMS. It arrives through server-side synchronisation as an email activity, and you then choose whether it becomes a case or is routed to a representative as an email record through a Record-type workstream. Both patterns are supported and they behave very differently.

Key facts

Two supported shapes. Route email as a case: an automatic record creation rule converts the email to a case, and the case is routed. Route email as a record: the email activity itself is the work item, routed to a representative through a Record workstream.
Email records use a Record workstream, not a Messaging one. That means intake rules rather than a channel binding, and no chat-style session behaviour.
Record routing requires unified routing to be provisioned and the record type enabled for queues. Basic routing rules will not move records once you are in unified routing until intake rules exist.
Intake rules are capped at 100 for records. They can look at up to two levels of related records and attributes, and they are evaluated in the order they appear in the decision list.
The documented setup sequence is: dedicated mailbox, server-side sync creating email records and queue items, a flow to route work items automatically, workstream, classification rules, route-to-queue rules, intake rules, queues and assignment method.
Capacity is consumed when an email record is assigned and it is your job to release it when the work is done. The docs are explicit about this — there is no equivalent of a chat session ending.
Record routing notifications appear in Copilot Service workspace only. Representatives working in a different app will not see them.
The record channel has the same platform quota as the others: 100 incoming work items per minute, adjustable through support.
Professional licensing gets queue-based email and automatic record creation rules, but unified routing — and therefore skills-based or capacity-aware email distribution — needs Enterprise.
Enabling unified routing has a documented effect on SQL load and runtime operations, so it is worth doing in a test environment first rather than flipping it in production on a Friday.

When to use / skip

Route email as a case in almost every situation. It is the pattern the rest of the product is built around: SLAs attach to cases, entitlements decrement against cases, knowledge search sits on the case form, and reporting has somewhere sensible to aggregate. The email record pattern exists for a genuine but narrow set of cases — high-volume enquiries where most messages never justify a case, general enquiry mailboxes, and back-office teams whose work genuinely is "answer the email and move on".

The trap is treating email record routing as the modern replacement for queue-based email because it lives in the newer admin UI. It is not. It is an alternative, it brings a capacity-release problem that queue-based email does not have, and it puts work items in front of representatives with no case context. If the client's answer to "does this email need a case?" is "usually", use cases.

Skip unified routing for email entirely if the client's email volume is low and their teams already work out of shared queues happily. Adding a routing engine to solve a problem nobody has is a reliable way to spend three sprints and make things worse.

Configuration decisions

Case or record. This is the design decision the whole email build hangs off, and it is worth making per mailbox rather than once for the whole client.
One mailbox or several. Separate mailboxes give you cleaner intake rules and clearer reporting than one mailbox with heavy classification.
Whether automatic record creation rules run before routing, and what happens to replies on existing threads so they update rather than spawn duplicates.
Push or pick for the email workstream. Email is one of the few places where pick genuinely works well, because there is no customer waiting on the line.
How capacity is released for email records — automatically on status change via a flow, or manually by the representative.
Which mailbox the outbound reply comes from, and whether that address matches the one customers wrote to.

Gotchas

Capacity leaks. If nothing releases capacity when an email record is finished, representatives silently fill up and stop receiving work. This is the number one email-record-routing incident and it is entirely avoidable.
Server-side sync is the foundation and it fails quietly. Mailbox approval, test-and-enable status and the Exchange throttling story all sit outside Dynamics and outside your control.
Automatic record creation rules and unified routing both want to act on the same email. Order matters and the interaction is not obvious from the UI.
Auto-responses and out-of-office replies create loops if the record creation rules are not filtered. Every client discovers this, usually in UAT, usually on a Friday.
Email records give the representative no case, so no SLA, no entitlement decrement and no case-based reporting. Clients who assumed SLAs applied to their email queue will be unhappy.
Enabling unified routing is not something to do casually in a live environment. Test it first.

Consultant notes

Ask the client to open their support mailbox and read the last twenty messages with you. That conversation settles case-versus-record in ten minutes, where a workshop would take a day.
If you go with email records, build and test the capacity-release mechanism in the same sprint. Do not leave it as a backlog item.
Demo threading. Show a customer reply landing on the existing case rather than creating a second one — it is the thing that goes wrong in every legacy system and the client will be watching for it.
Before go-live, check the from-address on outbound replies and the display name. Getting a reply from "CRM Service Account" undoes a lot of goodwill.
Push back on "route emails to individuals by skill" as a first release. Get queue-based email working, measure it, then decide whether the routing engine is earning anything.

Worth revisiting if Microsoft adds automatic capacity release for routed email records.