Knowledge article templates and categories

What it does

Templates prepopulate a new knowledge article with a fixed content structure plus default title, keywords and subject, so authors write the answer rather than the scaffolding. Categories are a separate hierarchical tagging structure used to group articles (and other records) for browsing, filtering and reporting.

Key facts

Templates are managed in Copilot Service admin center > Knowledge > Support experience > Article templates > Manage.
A template record has three parts: Template data (Name, Owner, Language), Article data (Title, Keywords, Subject), and Content authored in the rich text editor.
Templates are language-specific. A template created in English (United States) is only offered when authoring in that language, so a multilingual KB needs one template per language per format.
Creating, editing and deleting templates needs explicit privileges — it is a knowledge manager function, not an author one.
Applying a template copies its values into the new article. It is a one-time copy: editing a template later does not touch articles already created from it.
Templates can be surfaced on the Portal Knowledge Article Interactive Experience form via a web resource, if you need them in that authoring surface.
Categories are managed at Copilot Service admin center > Knowledge > Support experience > Categories > Manage, using the All Categories view.
A category record carries Title, Description, Display Order, Parent Category, and an auto-generated Category Number that appears after the first save.
Categories are hierarchical through the Parent Category lookup, and View Hierarchy on a category shows its parents and children.
Categories are not the same thing as Subjects. Subject is the older single-lookup taxonomy that templates prepopulate; Category is a many-to-many tagging structure. Both exist and both are used.
Article templates and Copilot's form-filling assistance coexist — the template supplies structure, and generated keyword and description suggestions fill in metadata.

When to use / skip

Templates are worth doing on any KB where more than about five people author, and essential where the content has a required legal or procedural shape — a fault-finding article that must always carry Symptoms, Cause, Resolution, and Escalation. Without a template, six authors produce six shapes and the KB reads as if it was assembled from a shared drive, which it effectively was.

They are not worth agonising over. Three or four templates covering the genuine article types is right. Twelve templates means authors pick the wrong one, and the ones nobody picks quietly rot.

Categories are the piece most projects get wrong in the other direction — they build an elaborate tree in a workshop and then discover that agents search rather than browse, so the tree gets tagged inconsistently and used by nobody. Build categories if there is a real consumer for them: a portal navigation structure, a search filter agents will use, or a reporting cut the client genuinely needs. If none of those exist, keep the taxonomy shallow and revisit later.

Configuration decisions

How many templates, and along which axis — article type (how-to, troubleshooting, policy) usually beats product line or department.
Which languages get templates, and who maintains the parallel set as templates evolve.
Whether Subject, Category, or both carry the taxonomy. Using both without a rule means neither is trustworthy.
Category depth and whether categories drive portal navigation, agent search filters, reporting, or all three — this determines how much rigour the tree needs.
Display Order values on categories, which matter as soon as anything renders the tree to users.
Whether authors can create categories on the fly or whether that is restricted to knowledge managers. Open creation gives you "Billing", "billing" and "Billing Issues" within a month.

Gotchas

Template changes do not propagate. Fix a typo in a template and every article already created from it keeps the typo. There is no re-apply.
Templates are bound to a language at creation and cannot be repointed. A multilingual rollout that starts with one template set will need the whole set rebuilt per language.
Template privileges are separate from article privileges. Authors will report that templates "don't appear" when the real issue is a missing role privilege.
Category Number only appears after the first save, so any integration keying on it must handle the create-then-read sequence.
Deleting a parent category does not tidy up children cleanly in the way people expect — check the hierarchy before deleting anything with descendants.
Categories are used across Customer Service, not just knowledge. A taxonomy designed purely for articles may collide with how another workstream wants to categorise cases.
Subject remains on the article form and is prepopulated by templates, so it stays visible even on projects that decided to standardise on Categories. Hide it deliberately or it will get filled in inconsistently.

Consultant notes

Run a content workshop with actual articles on the table and derive templates from what already exists, rather than designing templates first.
Demo the "template does not update existing articles" behaviour explicitly. Clients assume it works like a Word template and plan accordingly.
Push back on deep category trees. Ask who browses the tree and what they do next; if there is no answer, the tree is decoration.
Agree ownership of the taxonomy before go-live — one named person who approves new categories. This is the cheapest governance you will ever put in place.
If the client is multilingual, cost the parallel template maintenance into the support model, not just the build.

Worth another look if a second authoring language is added, or if the portal navigation design changes what categories have to support.