Dynamics 365 Customer Service: Hierarchical AI Email Classification with Categories and Subcategories

Microsoft's answer to that intake problem has expanded with hierarchical email classification in Dynamics 365 Customer Service. Tracked under Microsoft's AI at Work roadmap ID 576775 and Message Center notice MC1448701, the capability to classify inbound emails by both category and subcategory using the Case Management Agent is now generally available for web users in Worldwide (Standard Multi-Tenant) cloud environments. While the roadmap entry lists an August 2026 general availability window and was published to the unified roadmap catalog on October 16, 2026, Microsoft Learn release-plan documentation and Message Center records pinpoint the exact general availability date as August 21, 2026.

That date gap is itself a minor piece of Microsoft administrative trivia: Microsoft archived its standalone Dynamics 365 release plans starting in Fall 2026 and migrated ongoing Dynamics 365, Power Platform, and Dataverse tracking into the unified AI at Work roadmap. For customer service architects and Dataverse developers, however, the real story is what happens under the hood when an email arrives.

From Flat Labels to a Multi-Tier Taxonomy​

To appreciate why subcategories matter, it helps to look at how quickly this capability evolved. According to Microsoft Learn's 2026 release wave 1 documentation, Microsoft first introduced predefined email category classification for the Case Management Agent on April 10, 2026. That initial release allowed administrators to create a flat list of custom categories, analyze the subject and body of incoming emails as they synced into Dynamics 365 Customer Service, and write the selected category to a dedicated attribute on the email activity record.

Flat lists work well when your only goal is separating "Support Request" from "Spam" or "Thank You Note." They break down rapidly in larger service organizations where a billing dispute, a tax invoice request, and a subscription cancellation all belong under "Finance," yet require completely different queues, service-level agreements, or autonomous handling rules.

With the August 2026 update, administrators can define a custom taxonomy composed of both top-level categories and nested subcategories. When an inbound email arrives and meets administrator-defined qualification rules, AI within the Case Management Agent flow evaluates the email's subject and body against the active taxonomy names and descriptions, then stores the resulting category or subcategory directly on the Dataverse email activity record.

What Email Classification Does—and What It Does Not Do​

A common misconception around AI agent features in CRM platforms is that turning on a classifier magically resolves tickets on its own. In reality, email classification is an upstream triage signal, not an autonomous resolution engine by itself.

Writing a category or subcategory to the email record does not automatically delete junk mail, reply to a customer, or close a case unless your organization configures downstream processes to act on that value. Instead, Microsoft designed the stored classification attribute to serve as a structured input for:

• Case Management Agent workflows that handle routine issues or determine whether autonomous processing is appropriate.
• Automatic Record Creation (ARC) rules that decide whether an incoming email warrants creating a formal support case in the first place.
• Power Automate cloud flows and unified routing rules that branch logic based on the specific topic or subtopic.
• Reporting and analytics dashboards that track what kinds of messages are hitting support mailboxes before case creation even occurs.

By placing this evaluation step at the very front of the intake pipeline, service teams can filter out non-support noise—such as newsletters, thank-you replies, and promotional clutter—so neither human representatives nor downstream AI agents waste time and compute capacity on irrelevant messages.

Summary: Moving from a flat category list to a parent-child taxonomy lets administrators keep broad reporting buckets intact while giving routing rules and Power Automate flows fine-grained subcategories for execution.

Configuring the Taxonomy in Copilot Service Admin Center​

Because classification is an opt-in capability enabled by administrators, makers, or analysts for end users, nothing changes in a production environment until an admin defines the taxonomy and turns the feature on. Microsoft Learn's administration guide for configuring email classification outlines a straightforward setup path inside the Copilot Service admin center:

1. Navigate to Email settings > Email classification, and select Manage.
2. Under Define taxonomy, select + Add to open the Add category pane.
3. Enter a clear Category name and a plain-language Description that explains what kinds of emails belong in that bucket, and set the status to Active or Inactive.
4. To create a top-level category, leave the Parent field empty.
5. To create a subcategory, select the appropriate parent category directly above it in the hierarchy in the Parent dropdown, then select Save.

Because generative AI relies on the category names and descriptions rather than rigid keyword lists to infer intent, the quality of those descriptions is critical. If two subcategories have overlapping, vague descriptions—say, "Account Issues" and "Profile Problems"—the classifier has less signal to distinguish between a password reset and a billing address change.

Equally important is scope control. Microsoft explicitly notes in its administration documentation that email classification consumes AI resources. Rather than evaluating every message that touches your tenant, administrators can configure qualification conditions—filtering by specific target mailboxes, sender domains, languages, or other attributes—so only relevant inbound traffic triggers the Case Management Agent classification flow. Administrators can also manually override an assigned category or subcategory on an email record at any time, or disable classification entirely to stop processing new inbound emails without erasing historical labels already written to existing records.

Summary: Setup happens in the Copilot Service admin center by pairing parent-child categories with clear descriptions and strict mailbox or domain conditions to keep AI consumption focused.

Under the Hood: Dataverse Custom Action and Developer Guardrails​

For enterprise architects who need more control than the built-in automatic sync pipeline provides, Microsoft exposes the underlying engine through an unbound Dataverse custom action named msdyn_EmailClassificationCustomAction. Microsoft Learn's developer documentation (updated August 21, 2026 to align with the hierarchical release) reveals several technical details about how Dynamics 365 executes and tracks email classification.

When invoked via the Dataverse Web API (POST /api/data/v9.2/msdyn_EmailClassificationCustomAction) or the Power Automate Perform an unbound action connector step, the action evaluates an existing Dataverse email row (emailId) against the organization's active categories and updates two fields on the email record: Email category (AI) and Classification Status.

Prerequisites and Billing Realities​

According to Microsoft Learn's developer documentation for msdyn_EmailClassificationCustomAction, environments using this capability must meet several hard requirements:

• Email classification must be available and enabled in Dynamics 365 Customer Service.
• At least two active email categories must be configured in the taxonomy (if fewer than two are active, classification fails).
• Pay-as-you-go billing must be enabled for the environment, alongside required Copilot, AI agent, and cross-geography permissions.
• The calling user or service principal must hold Dataverse permissions to read the classification configuration and read/update the email record.

Hierarchical JSON Payloads and Status Codes​

When the custom action runs, it returns three properties: matchedCategoryId (the GUID of the matched msdyn_emailclassificationcategory record), status, and emailclassificationResponse. Developers building Power Automate flows should pay close attention to how these outputs are formatted: both status and emailclassificationResponse are returned as JSON-encoded strings rather than native JSON objects, meaning flow authors must verify the strings are not empty before wrapping them in a json() expression.

With hierarchical classification enabled, the parsed emailclassificationResponse payload can include specific fields that reflect the category-subcategory tree:

• category: The display name of the selected category.
• reason: An AI-generated explanation of why the message matched (useful for diagnostics or agent UI display, though Microsoft warns against using it for deterministic branching).
• selectedPath: An optional hierarchy path showing the route taken when hierarchical classification is enabled.
• finalCategory: An optional final hierarchy node selected by the service, which the action uses to resolve the specific Dataverse category record.
• confidence and evidence: Optional model confidence and supporting evidence fields for hierarchical results.

Meanwhile, the email record's Classification Status field tracks the lifecycle using four integer values: 0 (Default, no completed outcome), 1 (Skipped, eligibility conditions or permissions weren't met), 2 (Success, category matched and written), and 3 (Failed, an error occurred, such as having fewer than two active categories).

Two Expensive Traps to Avoid​

Microsoft's developer documentation highlights two operational pitfalls that every Power Platform architect should tape to their monitor:

1. Never double-classify an email: Do not invoke msdyn_EmailClassificationCustomAction on an email that has already been processed by built-in automatic email classification. Running classification twice on the same message consumes extra AI capacity, overwrites existing results, and can trigger downstream case-creation or routing workflows multiple times.
2. Prevent infinite flow loops: Because classifying an email updates the email activity row in Dataverse, any Power Automate flow triggered on "When a row is added, modified or deleted" for the Email table can accidentally retrigger itself when the classification result is written back. Always filter your trigger columns or inspect the Classification Status field before calling the action.

Summary: Whether using built-in classification or the msdyn_EmailClassificationCustomAction API, administrators and developers must account for pay-as-you-go AI consumption, requires at least two active categories, and guard against duplicate execution loops.

Practical Takeaways for Dynamics 365 Administrators​

Does adding subcategories to AI email triage solve every customer service bottleneck? Of course not. Microsoft's release notes tout time savings and lower processing costs, though as is standard for roadmap entries, those business-value statements come without published benchmark percentages or latency metrics. Furthermore, classification is only as reliable as your taxonomy design and downstream rules; it is an administrative sorting mechanism, not a security boundary or an enterprise anti-spam gateway.

Still, for organizations running high-volume support desks in Dynamics 365 Customer Service, moving from a flat category list to a two-tier category and subcategory taxonomy closes a major gap in intake automation. By letting the Case Management Agent inspect the subject and body of incoming emails, tag them with a specific subcategory GUID, and hand that structured result off to Automatic Record Creation rules and Power Automate before a ticket is ever born, IT teams can keep their case queues cleaner and their human agents focused on actual problems.