SfSkills Domains Docs GitHub

Home / architect / knowledge-taxonomy-design

knowledge-taxonomy-design

Use when designing or restructuring a Salesforce Knowledge taxonomy: Data Category Group structure, hierarchy depth, article type selection, article lifecycle governance (Draft/Published/Archived), Validation Status gating, and content gap analysis via KCS methodology and Search Activity Gaps.

Open the skill folder on GitHub

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:

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:

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:

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

SituationRecommended ApproachReason
Single product, <500 articlesOne Data Category Group with 2 levels (Topic, Sub-Topic)Overhead of multiple groups not justified; single group with flat hierarchy is easy to maintain
Multi-product, each product has dedicated agent teamsOne group per major dimension (Products, Topics) — up to 3 activeKeeps each dimension independently navigable; avoids deep combined tree
Articles serve both internal agents and Experience Cloud customersSeparate Validation Status tracking for each audience tier using custom picklist valuesDefault three values often insufficient; custom values allow audience-specific quality gates
Org has high case volume and agents don't author articlesImplement KCS Solve Loop — require article search before case close, prompt creation on zero resultsTurns case volume into content creation signal; Search Activity Gaps closes the feedback loop
Existing deep taxonomy (4–5 levels) with poor search performanceFlatten to 2–3 levels during a structured migration: map leaf categories to new parents, re-assign articles in bulk via Workbench or Data LoaderDeep hierarchies penalise search relevance; flattening improves SOSL scoring of category-matched articles
Validation Status not enabled but org wants to go KCSEnable carefully — cannot disable without clearing all values; plan the picklist design before enablingOne-way enablement means the picklist design must be final before go-live

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:

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

ArtifactDescription
Data Category Group layoutSpreadsheet or diagram mapping Group names, hierarchy levels, category nodes, and estimated article counts per node
Article lifecycle governance docMatrix of Publication Status × Validation Status × role permissions showing who can create, review, publish, and archive
KCS Solve/Evolve process definitionStep-by-step process guide for agents (Solve Loop) and domain experts (Evolve Loop) with entry/exit criteria per stage
Content gap baselineExported Search Activity Gaps list at taxonomy go-live, used as baseline for gap-closure measurement
Migration sequence planOrdered steps for re-assigning existing articles to new category structure, with Data Loader field mapping

Package files