Knowledge Taxonomy Design

Knowledge Taxonomy Design

Use this skill when designing or restructuring the taxonomy that underpins a Salesforce Knowledge base. It activates when a practitioner must decide how to organise Data Category Groups and hierarchy levels, govern article lifecycle (Draft → Published → Archived), gate publication through Validation Status, and identify content gaps using Search Activity Gaps and KCS methodology. It produces a structured taxonomy model, a lifecycle governance design, and a content gap analysis plan grounded in platform limits.

Before Starting

Gather this context before working on anything in this domain:

• How many distinct article audiences or products exist? Each audience or product may warrant its own Data Category Group. Salesforce allows up to 5 Data Category Groups per object by default (maximum 5 total across the org; only 3 are active at once without a support request). Exceeding this forces awkward flattening inside a single group.
• What is the most common wrong assumption? That more hierarchy levels improve findability. Deep hierarchies (more than 3 levels for most orgs) increase categorisation overhead, cause miscategorisation, and make Search Activity Gaps analysis harder to act on. Flatter taxonomies with broader parent categories and specific leaves outperform deep trees in agent search speed.
• What limits are in play? 5 Data Category Groups per org (3 active by default), 5 hierarchy levels per group, 100 categories per group; article types are fixed-shape metadata — adding fields requires a new article type version; Validation Status is a single org-wide setting, not per-article-type; Search Activity Gaps dashboard retains data for rolling 90 days.

Core Concepts

Data Category Groups and Hierarchy

A Data Category Group is a named classification dimension applied to Knowledge articles (and Cases and Answers, if enabled). Each group holds a tree of categories up to 5 levels deep with up to 100 total categories per group. The hierarchy is navigated top-down in the agent console and Experience Cloud, so breadth at the second level determines how quickly agents locate content.

Salesforce enforces a default limit of 3 active Data Category Groups per org (maximum 5). Activating a group requires assigning it to the Knowledge object via Setup → Data Category Group Assignments. Deactivated groups remain in the system but are invisible to end users and agents — this is useful for managing taxonomy migrations without data loss.

Hierarchy design principle: Use 2–3 active levels for most orgs. Level 1 is the primary dimension (Product, Business Unit, or Topic). Level 2 is a sub-dimension (Product Family, Support Tier, or Subject Area). Level 3 is optional and should only exist where the article corpus is large enough to warrant it (>200 articles in the parent). Levels 4–5 are rarely justified and significantly increase maintenance burden.

Article Lifecycle: Draft → Published → Archived

Every Knowledge article moves through a defined lifecycle controlled by Validation Status and Publication Status:

• Draft — Article is being authored. Visible only to agents with "Manage Articles" permission. Cannot surface in customer-facing channels or Agentforce RAG.
• Published — Article is live. Visible to configured audiences per Data Category visibility rules. Searchable in Service Console, Experience Cloud, and Einstein RAG contexts.
• Archived — Article is withdrawn from search results and channel surfaces but remains in the system for compliance and audit. Archived articles can be restored to Draft. Hard deletion is a separate action requiring "Delete Knowledge" permission.

Validation Status is an additional gating layer independent of Publication Status. It supports three built-in states — Not Validated, Work In Progress, Validated — and can be extended to custom picklist values via the KnowledgeArticleVersion standard object. A common pattern gates publication on Validation Status = Validated, enforced through a Before-Save Flow or process that blocks status transitions. This is the KCS "Evolve Loop" integration point.

Validation Status as a Quality Gate

When Validation Status is enabled (Setup → Knowledge Settings → Enable Validation Status), it appears on every article. The setting is binary and org-wide; it cannot be toggled per article type. Once enabled, it cannot be disabled without clearing all existing Validation Status values first.

For KCS-aligned orgs, the standard pattern maps the KCS workflow stages to Validation Status:

• Solve Loop — article created during case resolution, status = Work In Progress, published immediately so agents can find and reuse it, refinement deferred
• Evolve Loop — article reviewed by a domain expert, status moved to Validated once content meets quality bar

Content Gap Analysis via Search Activity Gaps

The Search Activity Gaps dashboard (Knowledge → Search Activity Gaps) shows search terms entered by agents and customers that returned zero results or low-CTR results. It is the primary signal for missing or poorly-titled articles. The dashboard retains 90 days of data and is segmented by channel (Internal, Primus, Experience Cloud).

KCS Solve Loop practice embeds article creation directly into case resolution: when an agent searches for an article during case work and finds nothing useful, they create a new article before closing the case. This turns every case into a content signal. Search Activity Gaps then validates that the new articles are eliminating the gaps over subsequent weeks.

Common Patterns

Product-First Category Group Layout

When to use: Multi-product orgs where agents are assigned to product queues and need to filter articles to their product scope quickly.

How it works:

1. Create one Data Category Group named Products with Level 1 = product family, Level 2 = individual product or version.
2. Create a second Data Category Group named Topics with Level 1 = topic type (How-To, Troubleshooting, Reference, Release Notes), Level 2 = subject domain.
3. Assign both groups to the Knowledge object. Leave the third slot for a future Regions or Audience group if needed.
4. Each article is tagged to one product leaf and one topic type. Agents filter by product first, topic second.

Why not a single deep tree: Combining product and topic in one tree forces articles to live at deep nodes (e.g., Products → Cloud CRM → Admin → Troubleshooting → Login). A single hierarchy means agents must navigate 4–5 levels to narrow results. Two flat groups allow independent filters that compose at query time.

KCS Solve-and-Evolve Governance Model

When to use: Any org where agents handle high case volume and content quality has historically degraded because only specialists could publish articles.

How it works:

1. Enable Validation Status in Knowledge Settings.
2. Map Validation Status = Work In Progress to "published, agent-authored" articles (Solve Loop). Agents create and publish articles during case work; status signals the article needs expert review.
3. Map Validation Status = Validated to "reviewed, canonical" articles (Evolve Loop). Domain experts review Work In Progress articles weekly and promote to Validated once content meets quality criteria.
4. Build a Knowledge dashboard filtered to Validation Status = Work In Progress as the review queue for domain experts.
5. Track Search Activity Gaps weekly. When a gap disappears (zero-result search term now returns results), attribute it to the relevant Solve Loop article that closed the gap.

Why not gate all publication on expert review: KCS principle is that a timely imperfect article is more valuable than a perfect article delayed by approval. Gating on expert review introduces a bottleneck that kills agent adoption. The Solve Loop publishes immediately; the Evolve Loop improves over time.

Decision Guidance

Recommended Workflow

Step-by-step instructions for an AI agent or practitioner working on this task:

1. Audit current state. Count existing Data Category Groups, active groups, hierarchy depth per group, total category count per group, and article count per leaf category. Export via Setup → Data Categories or query DataCategory and DataCategoryGroup objects via SOQL. Identify groups that are inactive or over-allocated.
2. Define taxonomy dimensions. Identify the independent classification axes that agents and customers use to find articles (Product, Topic Type, Audience, Region). Each independent axis is a candidate for its own Data Category Group. Confirm total required groups ≤ 3 active (request limit increase if 4–5 are genuinely required).
3. Design hierarchy depth. For each group, map the category tree. Target 2–3 levels for most groups. Apply the >200 articles rule before adding a Level 3 node. Document the proposed tree in a spreadsheet before creating categories in Setup.
4. Design article lifecycle and Validation Status model. Decide whether Validation Status is required. If yes, define the picklist values before enabling (default: Not Validated, Work In Progress, Validated; extend only if a distinct custom state is needed). Map each status to a role and a workflow step. Document who can transition from each status.
5. Implement and migrate. Create Data Category Groups and category trees in Setup. Re-assign articles to new categories using Data Loader (update DataCategorySelection records). Archive deprecated categories after migration is verified.
6. Set up content gap analysis. Enable Search Activity Gaps if not already active. Baseline the current gap list. Communicate the KCS Solve Loop expectation to agents: search before closing, create if nothing relevant exists. Schedule a weekly review of the Search Activity Gaps dashboard with domain expert reviewers.
7. Validate and iterate. After 30 days, review: category distribution (are articles evenly distributed or clustered in a few nodes?), Search Activity Gap trend (is the gap list shrinking?), Validation Status distribution (is Work In Progress queue growing faster than Evolve Loop can clear?). Adjust taxonomy or process based on findings.

Review Checklist

Run through these before marking work in this area complete:

• Total active Data Category Groups ≤ 3 (or limit increase has been requested and approved)
• No Data Category Group exceeds 5 hierarchy levels or 100 categories
• Each article type's field set is documented and matches the article audience's information need
• Validation Status picklist values are defined and mapped to workflow roles before enablement
• KCS Solve Loop process is documented and communicated to agent population
• Search Activity Gaps dashboard is accessible and baseline gap list is captured
• Article migration or re-categorisation sequence is planned with rollback approach

Salesforce-Specific Gotchas

Non-obvious platform behaviors that cause real production problems:

1. Validation Status cannot be disabled after enablement — Once you enable Validation Status in Knowledge Settings, you cannot turn it off without first clearing all existing Validation Status field values on every article version. In orgs with thousands of articles, this is a significant data operation. Design the picklist before enabling; do not enable to "try it out" in production.
2. Only 3 Data Category Groups are active by default — Salesforce limits orgs to 3 active Data Category Groups by default, even though the object supports up to 5. Attempting to activate a fourth group silently fails in older UI or throws a Setup error in newer UI. If a design genuinely requires 4–5 groups, open a Salesforce support case to raise the limit before the architecture is locked.
3. Archived articles remain in SOSL results until re-index — When an article is archived, it does not immediately disappear from search results in all contexts. Experience Cloud search may continue surfacing archived articles for minutes to hours depending on search index refresh timing. Agents may link archived articles to cases during this window. Build article lifecycle communications to manage agent expectations.
4. Data Category visibility is separate from article Publication Status — An article can be Published but invisible to an agent or portal user if their profile's Data Category visibility does not include the article's category. This is a common source of "I can't find the article I just published" support requests. Always verify Data Category Group Assignments and visibility rules together with publication tests.
5. Search Activity Gaps uses a 90-day rolling window only — The dashboard does not persist historical snapshots beyond the rolling 90-day window. If you want to track gap closure trends over quarters or demonstrate KCS ROI to leadership, you must export the gap list regularly and store it externally. There is no API to programmatically export Search Activity Gaps data; it is a UI-only dashboard.

Output Artifacts

Related Skills

• architect/knowledge-vs-external-cms — Use alongside when deciding whether content should live in Salesforce Knowledge vs an external CMS with CMS Connect; taxonomy design only applies once the Knowledge decision is confirmed
• architect/service-cloud-architecture — Taxonomy design feeds the knowledge deflection strategy section of a Service Cloud architecture engagement
• architect/ai-ready-data-architecture — When Agentforce or another RAG system will ground on Knowledge articles, the taxonomy and Validation Status design directly affects RAG retrieval quality