Almanac
Microsoft/d365csDynamics 365

Consultant-focused KB for Microsoft Dynamics 365 Customer Service: implementation notes, gotchas, and configuration decisions beyond the official docs — across case management, queues and routing, knowledge base, SLAs, omnichannel, agent experience, Copilot, analytics, and administration.

feature-copilot-knowledge-drafting.mdv1 · history
CurrentApplies to EnterpriseUpdated 6 days agoSource Microsoft Learn

What it does

The Customer Knowledge Management Agent reads resolved cases and closed conversations, compares them against existing knowledge, and drafts new articles where it finds a gap. It runs in real time on resolution and in batch across historical records. Separately, reps can be prompted at case resolution to propose an article themselves, Copilot doing the drafting.

Key facts

  • The Customer Knowledge Management Agent is GA. It went to public preview on 31 March 2025 and GA on 31 October 2025 under the 2025 wave 2 plan. It is Customer Service only, not Contact Center.
  • The rep-initiated route — Knowledge creation (preview) under Support experience > Knowledge, with "Let representatives use Copilot to propose new knowledge based on case information during or after case resolution" — is still preview. Two different features, easy to conflate.
  • Runs on pay-as-you-go. You need a Power Platform PAYG plan against an Azure subscription, and Copilot Studio message consumption applies. Without PAYG configured, nothing runs.
  • Needs connection references for Microsoft Dataverse and Copilot Studio, set up from Support experience > Knowledge > Customer Knowledge Management Agent > Manage. The Prerequisites section shows whether they're ready; if automatic setup fails you configure them by hand and publish.
  • Real-time and historical creation are separate switches, and separate again for cases versus chat and messaging conversations.
  • Historical batches process up to 100,000 cases or conversations. Once started, the process is long-running and cannot be stopped.
  • Attribute mapping limits: 10 one-to-one attributes and 6 one-to-many. Case Title and Description cannot be removed; Email Content and Conversation Summary cannot be modified.
  • Custom record types are supported up to 5, and that capability is flagged as preview, as are automatic article updates (minor versions) and the enhanced agent review draft experience.
  • Auto-publish is off by default. Turn it on and you choose the audience: internal only (reps and Copilot), or internal and external, which includes portals.
  • The default article shape is Issue / Cause / Resolution. Custom templates are supported for historical creation, one template per rule.
  • The agent strips personal data from case content before drafting, and Microsoft is explicit that it may not catch everything.
  • Knowledge draft generation is more regionally restricted than most Copilot features and is documented as English only for language support.

When to use / skip

This is worth real money to a client with high case volume and a knowledge base that has stagnated, which describes most service desks after year two. The historical batch in particular is the closest thing in the product to a one-shot knowledge base refresh.

Skip it, or defer it, where the client has no knowledge governance to speak of. An agent that autonomously produces drafts into a base nobody curates just moves the mess. It also needs someone to own review, and "the service manager will review them" is not an answer that survives 300 drafts in the first week.

The English-only language support rules it out for a lot of European and APAC deployments as the primary mechanism, though it can still work for an English-language tier-1 base.

Configuration decisions

  • Real-time, historical, or both — and whether conversations are in scope as well as cases. Most projects start real-time on cases only.
  • The rules that select which cases qualify. Owned-by, product line, category, resolution type. Unfiltered is the wrong answer; every duplicate password-reset case becomes a candidate.
  • Auto-publish on or off, and if on, internal-only or internal and external. External auto-publish is a one-way door in reputational terms.
  • Which attributes feed the draft, within the 10 and 6 limits, and whether custom fields carrying the real resolution detail need to displace defaults.
  • Article template: stick with Issue / Cause / Resolution, or author custom templates per rule to match the client's existing house style.
  • Who reviews drafts, how they're notified, and whether Timeline and Timeline highlights are enabled on the case form to support the review experience.

Gotchas

  • The historical batch cannot be stopped once it starts. Run a small scoped rule first; do not point it at 100,000 records to see what happens, because you'll be paying for all of it.
  • PAYG billing is consumption-based and easy to under-forecast. Historical runs and shadow-style testing all consume. Get the client's finance owner to agree a budget before the first batch.
  • Connection references are the most common failure. If the automatic setup silently doesn't complete, the agent appears configured and produces nothing.
  • Personal data scrubbing is best-effort. Publishing to an external audience without human review is where a client's incident report comes from — say this out loud during design.
  • The rep-initiated knowledge creation path is preview and separately licensed in terms of risk. Don't let a client hear "GA" for the agent and assume it covers the resolution-time prompt too.
  • Custom record type support caps at 5 and is preview. Clients with a bespoke service model built on custom tables should validate this early rather than assume parity with cases.
  • Draft quality tracks resolution note quality directly. If reps close cases with "resolved" in the resolution field, the drafts will be worthless and the client will blame the AI.

Consultant notes

  • Run the historical batch against one narrow, high-volume category as a pilot and review every draft manually. That review is your evidence for whether the wider run is worth funding.
  • Insist on a named knowledge owner before enablement. This feature converts a technology problem into a process problem, and the process side is where projects fail.
  • Demo the review-and-edit experience, not the generation. Clients need to see the human control point or they will either fear it or over-trust it.
  • Check that Timeline and Timeline highlights are on the case form and that reps have article edit privileges before go-live — the review flow depends on both and neither is guaranteed on a customised form.
  • Push back hard on external auto-publish in the first release. Get six months of internal-only drafts and a curation habit first.

Worth another look when custom record types and automatic article updates leave preview, or if language support moves beyond English.

Was this accurate?