A knowledge manager opens a familiar article and notices that the old suggestion experience is no longer part of the job. The article itself is still useful. What disappeared was the shortcut that proposed its keywords and description.
The practical answer is not to rebuild the knowledge base or let a new assistant rewrite every record. Replace the retired suggestion with a controlled authoring step. Generate a proposal, compare it with the article, let a named person approve it, and prove that people can still find the right answer.
Microsoft says AI-suggested knowledge article keywords and descriptions were deprecated on December 15, 2025, and support ended on January 31, 2026. Its recommended replacement is Fill forms using Copilot. That is a product change, but the harder part is operational. A generated field is still only a proposal.
The old suggestion ended but the fields still matter
Microsoft's knowledge article guidance gives each field a real job. The title should state the article's subject and purpose. Keywords are used when searching the knowledge base. The description appears in search results and is also used for search engine optimization.
- 1Record the baselinePreserve current fields, ownership, language, and expected searches.
- 2Choose a mixed sampleInclude easy, difficult, translated, and outdated articles.
- 3Generate a proposalUse the replacement experience without accepting every field together.
- 4Review and searchCheck meaning, customer language, and realistic retrieval.
- 5Expand carefullyMove in small batches with rollback values and a named owner.
That means weak metadata creates a very ordinary failure. An agent searches with the words a customer used, sees three vague results, opens the wrong one, and gives up. Before changing tools, use your existing knowledge gap review to identify articles that are hard to find rather than assuming the whole library is broken.
The Microsoft deprecation notice points to the new form-filling route. It does not remove the need for clear titles, useful search language, or editorial ownership.
Preserve what works before changing anything
Start with evidence, not settings. Export or record the current title, keywords, description, language, status, owner, and article identifier for a small test group. Add the search phrases agents actually use and note which article they expect to find. If you cannot reproduce today's result, you will not know whether the change helped.
Choose a mixed sample. Include one article that is easy to find, one with specialist vocabulary, one with a customer phrase that differs from the internal product term, one translated article, and one article with an outdated description. This exposes different failure modes without risking the whole library.
Give three people clear roles. The author confirms the article's meaning. A reviewer checks the generated metadata. A service representative tests retrieval using realistic customer wording. If one person does all three, a plausible-looking suggestion can pass without anyone proving it works.
A change like this deserves the same release gate used for customer service AI. The risk is smaller than an autonomous reply, but the principle is the same. Do not promote generated content merely because the system produced it.
Test one article from authoring to retrieval
Use one stable, published article first. Preserve its current metadata, then use the replacement experience to propose the title, keywords, and description. Review each field separately. Do not accept all three with one click just because one field looks good.
Microsoft says keywords are used for knowledge search and should be separated by commas. That makes a retrieval test concrete. Search with a customer's phrase, an agent's phrase, a common synonym, and the exact product term. Confirm that the intended article appears without burying several unrelated articles above it.
| Field | Accept when | Reject when |
|---|---|---|
| Title | It names the customer problem and the article's purpose | It repeats internal jargon or promises more than the article explains |
| Keywords | They reflect real search language and useful synonyms | They are broad, duplicated, or absent from the article's meaning |
| Description | It states the outcome, scope, and important limit | It is generic, promotional, or hides who the article is for |
| Ownership | One person can explain and approve the change | Approval belongs to an unnamed team or an unattended automation |
| Retrieval | Expected searches return the intended article | The change improves wording but makes the article harder to find |
Review meaning before convenience
Copilot can reduce typing. It cannot decide whether a suggested word matches how your customers describe the problem, whether a regional term is safe in every language, or whether a description exposes an internal-only detail. Keep those decisions with the reviewer.
The same discipline used in a customer service QA scorecard works here. Fail a materially wrong result before scoring style. A polished description that changes eligibility, omits a safety limit, or points to the wrong product should not receive partial credit.
Watch translations separately. Do not copy English keywords into Arabic, Russian, Dutch, or Spanish when customers search differently. Preserve product identifiers where necessary, but test natural phrases in each language. A translated article is not ready because its body reads well if its metadata makes it invisible.
Move the library in controlled batches
After the first article passes, expand to a small batch with the same owner and acceptance evidence. Keep the previous values long enough to compare results and restore them if retrieval gets worse. Review failures by cause: weak source content, unclear title, unsuitable suggestion, missing synonym, translation issue, or search configuration.
If generated metadata is part of a wider customer-facing AI change, test the answer path too. The same article may be used by representatives, search, and an AI assistant. A useful AI chatbot test checks whether the right source is retrieved before judging the final wording.
DripTell is not the system that authors Dynamics 365 knowledge fields. Its relevant role is downstream: keeping customer context and ownership visible through customer service workflows and governed AI assistance. The replacement is successful when people find the right article faster and the customer gets the right answer, not when every empty field becomes filled.
Frequently Asked Questions
Is the old Dynamics 365 metadata suggestion still supported?
No. Microsoft says the AI-suggested knowledge article keywords and descriptions feature was deprecated on December 15, 2025, and support ended on January 31, 2026.
What replacement does Microsoft recommend?
Microsoft recommends Fill forms using Copilot to generate knowledge article keywords and descriptions. Treat the result as a proposal that still needs review and retrieval testing.
Should we update every knowledge article at once?
No. Start with a mixed test sample, preserve the current values, prove retrieval, and then move through controlled batches. A mass rewrite makes failures harder to diagnose and recover.
How do we know the new metadata is better?
Use realistic searches from customers and service representatives. The intended article should be easier to find without pulling unrelated content above it, and a named reviewer should confirm that the title, keywords, and description remain accurate.
Want help applying this guide?Ask the DripTell team
From reading to action
Want help applying this to your business?
Share your details. We will read the article you are on and start with a useful answer for your team.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy
