Most of the work is designing the right Data Category taxonomy. The configuration mechanics are straightforward; the taxonomy design is what determines whether the Knowledge base is usable.
- Design the taxonomy
Workshop with content authors and users to define the right Data Category Groups (typically Product, Region, Audience) and the categories under each. Keep depth to 2 or 3 levels. Document the taxonomy before configuring.
- Create the Data Category Groups
Setup, Data Category Groups, New. Create one Group per top-level axis. Add Data Categories in the hierarchy. Activate when ready.
- Configure Data Category Visibility
Setup, Data Category Visibility. Define which roles, profiles, or permission sets can see articles tagged with which categories. This enforces the access model.
- Update Article Page Layouts
Ensure the Data Categories section is on the Knowledge article page layout so authors can assign categories.
- Train authors
Document the taxonomy and train authors on which categories to apply to which articles. Without discipline, articles get mis-tagged and the browse experience degrades.
- Build reports and dashboards
Create reports grouped by Data Category to monitor article volume per category, popularity, and review cadence. Use these to prioritize content work.
- Hierarchies over 3 levels deep become unusable. Authors and readers cannot mentally navigate them; aim shallow.
- Data Category Group changes (rename, restructure) can cascade through articles unpredictably. Plan changes carefully in a sandbox first.
- Articles can have multiple categories per Group. Authors sometimes assign every category that seems vaguely relevant; train discipline.
- Data Category Visibility is sticky. Once configured, removing a role from a category does not retroactively rebuild the visibility; cache invalidation requires touching the article.
- Topics and Data Categories coexist but serve different purposes. Do not collapse them into one structure; the two-layer model is intentional.