Data Category for Articles
A Data Category for Articles in Salesforce is a label inside a Data Category Group that classifies Knowledge articles by topic, product, region, or any taxonomy a team wants to browse Knowledge by.
Definition
A Data Category for Articles in Salesforce is a label inside a Data Category Group that classifies Knowledge articles by topic, product, region, or any taxonomy a team wants to browse Knowledge by. Authors assign one or more categories when they create or edit an article. Readers in the Knowledge tab, the Service Console, or an Experience Cloud site then filter articles by category to find what they need.
Data Categories are an actively supported part of Salesforce Knowledge configuration, not a legacy feature. They organize content into a parent-child hierarchy, which suits product lines and geography where a natural tree exists. They also drive Data Category Visibility, the access model that decides which articles a given role, profile, or permission set is allowed to see.
How Data Categories shape a Knowledge base
Groups, categories, and the hierarchy
A Data Category Group is the top container, such as Products or Regions. Inside it, Data Categories form a tree. Under Products you might place Hardware, then Laptops, then Pro Series. Each child sits beneath its parent and inherits that context. An article tagged at a deeper level still surfaces when a reader browses a level above it, so a Pro Series article appears under Laptops and Hardware too. By default a group holds up to 100 categories and a hierarchy can run up to 5 levels deep. You can ask Salesforce to raise those limits, but most teams never need to. The group is the unit you assign to Knowledge, and only an active group with at least one category does anything useful. Think of the group as the dimension you classify along (what product, what region) and the categories as the values within that dimension. Keeping each group focused on a single dimension is what keeps the structure readable for both authors and readers.
Tagging articles with categories
When an author edits a Knowledge article, a Data Categories panel lists every available group. The author picks one or more categories from each group that fits the content. An article can carry categories from several groups at once, so a single piece might be tagged Laptops in Products and EMEA in Regions. As of Spring 20, an article can hold up to 50 data category selections, which is generous enough to catalog content precisely without forcing a choice. Authors only see and can pick categories their own role, profile, or permission set is allowed to see, so the editing experience already respects visibility. You can also assign categories in bulk through the API or Data Loader by updating the article version records, which helps when you reclassify a large back catalog. Good tagging discipline matters more than the tooling. A category nobody applies consistently is worse than no category at all, because readers learn to distrust the filter.
Browsing and searching by category
Readers get a category browser in the Knowledge tab, the Service Console, and Experience Cloud. They drill down through the tree to narrow a long list of articles to the slice they care about. Search results can be filtered the same way, so a query for "battery" can be scoped to the Charge Controllers branch. Many Knowledge bases build their main navigation directly on top of the top-level group, with sub-categories forming the menu beneath. This gives a customer a familiar product-style path into the content. Because the hierarchy is shared between authoring and reading, the structure an admin designs in Setup is the exact structure a customer walks through on the site. That tight coupling is powerful, but it also means a confusing taxonomy hurts everyone at once. A clean two or three level tree gives readers a fast path to the answer; a sprawling five level tree buries it.
Data Category Visibility and access
Data Category Visibility is the access model attached to categories, and it works differently from normal record sharing. You set visibility on roles, on permission sets, or on profiles, choosing All, None, or Custom. Custom lets you grant a specific sub-tree, so a partner role might see only the Public branch of a group while staff see everything. This is how a Knowledge base keeps internal-only articles off a customer-facing Experience Cloud site, or shows EU-specific guidance only to EU users. Visibility flows down the hierarchy: grant a parent category and the children come with it unless you narrow the selection. There is also a default visibility setting that applies to users without an explicit role-based assignment. A common gotcha is forgetting that category visibility and object-level access stack. A user needs read access to the Knowledge article and visibility on its categories before the article shows up. Treat category visibility as a refinement on top of standard access, not a replacement for it.
Data Categories compared with Topics
Topics are the flat, tag-style alternative to Data Categories, and the two are designed to coexist. Data Categories give you a governed, hierarchical taxonomy that also drives access. Topics give you free-form labels that readers and authors can apply for community-style discovery in Experience Cloud. An article can carry both at the same time. A practical split is to use Data Categories for the official structure that mirrors your products and controls who sees what, then use Topics for emergent themes that do not deserve a permanent place in the tree. Because Topics carry no visibility rules, never lean on them to hide sensitive content. If access matters, the classification belongs in a Data Category. Many mature Knowledge bases run both: the category tree powers the formal browse and security, while a topic catalog captures the language readers actually use when they search.
Reporting on category coverage
Article reports can group by Data Category, which turns the taxonomy into a content-management dashboard. Grouping by category surfaces coverage gaps, the branches that hold few or no articles and may need new content. It also shows popularity, the categories that draw the most reads and deserve continued investment. Pairing category with the article validation status highlights where outdated content clusters, so a review effort can target the branches that customers actually open. Teams that run these reports on a regular cadence keep the taxonomy honest. They retire categories that never earned content, promote the ones starved of articles, and schedule reviews where stale content piles up. Without this loop a category tree quietly drifts out of sync with the real library, and the browse experience degrades even though every individual article looks fine. The taxonomy is a living structure, and reporting is how you keep it aligned with what the Knowledge base contains.
Designing a taxonomy that lasts
The most common design mistake is an over-deep hierarchy. A five-level tree can look logical on a whiteboard yet feel unusable to the author tagging an article and the reader hunting for one. For production use, two or three levels is the sweet spot. The second mistake is too many groups. One or two well-chosen groups beat five overlapping ones that force authors to guess where a category lives. Design the structure with the people who will tag content every day, not in an admin vacuum, because they know which distinctions actually matter. Decide up front whether a group represents product, audience, region, or lifecycle, and keep each group to a single idea. Plan visibility at the same time as structure, since the branches map directly onto who can see what. A taxonomy built this way stays browseable as the library grows, while one bolted on after the fact tends to collapse under its own complexity.
Set up Data Categories for Knowledge articles
Setting up Data Categories for articles means creating a Data Category Group, adding the category values inside it, then assigning the group to Knowledge and granting visibility. You do this in Setup before authors can tag articles.
- Create the Data Category Group
In Setup, search for Data Category Setup and create a new group. Give it a name that names the dimension you classify along, such as Products or Regions. New groups start inactive.
- Add and arrange categories
Open the group and add categories. Use the actions on each category to add children and build the tree. Keep it to two or three levels and a manageable number of values so it stays browseable.
- Activate and assign the group
Activate the group, then assign it to Knowledge so articles can use it. Until the group is active and assigned, authors will not see it in the Data Categories panel.
- Set Data Category Visibility
Open Data Category Visibility Settings and choose All, None, or Custom for each role, profile, or permission set. Use Custom to expose only the branches a given audience should see, and confirm the default visibility too.
- Tag and verify
Edit a Knowledge article, pick categories in the Data Categories panel, and publish. Browse the Knowledge tab or your Experience Cloud site as a test user to confirm the article appears under the right branch.
The label for the Data Category Group; it should name the single dimension the group classifies along, like Products or Regions.
A group must be active and assigned to Knowledge before its categories appear to authors; new groups start inactive.
Per role, profile, or permission set, this controls which category branches a user can see, and therefore which articles surface for them.
The fallback visibility applied to users without an explicit role-based assignment for the group.
- A group does nothing until it is active and assigned to Knowledge; a new inactive group is invisible to authors.
- Category visibility stacks with object access. A user needs read on the article and visibility on its categories before it appears.
- Default limits are 100 categories per group and 5 hierarchy levels; raising them needs a request to Salesforce, but deep trees usually hurt usability.
- Topics carry no visibility rules, so never use them to hide sensitive content. Use a Data Category when access depends on the classification.
Prefer this walkthrough as its own page? How to Data Category for Articles in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Work with Data CategoriesSalesforce
- Data Category VisibilitySalesforce
Straight from the source - Salesforce's reference material on Data Category for Articles.
Hands-on resources to go deeper on Data Category for Articles.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Data Category for Articles in Salesforce Knowledge?
Q2. Beyond browsing and search, what else do Data Categories for Articles control?
Q3. How do Topics relate to Data Categories on Knowledge articles?
Discussion
Loading discussion…