Category Group for Articles
A Category Group for Articles is a named container in Salesforce that holds a hierarchy of Data Categories used to classify Knowledge articles.
Definition
A Category Group for Articles is a named container in Salesforce that holds a hierarchy of Data Categories used to classify Knowledge articles. Each group represents one dimension of your content, such as Products, Geography, or Customer Type, and the categories inside it form a parent-and-child tree. Authors tag articles against categories in the group, and readers filter by those categories to find the right content. The same Data Category infrastructure also serves Ideas and the legacy Answers feature, but for Knowledge the Category Group is how articles get organized and secured.
A Category Group does two jobs at once. It gives articles a browsable taxonomy, and it controls who can see what through Data Category Visibility settings tied to roles, profiles, or permission sets. You build and manage groups in Setup under Data Category Setup. Salesforce lets you keep up to five active groups, each holding up to 100 categories across up to five hierarchy levels. Good group design pays off everywhere downstream, because search, browse, reporting, and article access all read from the structure you define here.
How Category Groups shape a Knowledge program
Anatomy of a Category Group
A Category Group has a Group Name, a Label that users see, and a tree of Data Categories beneath it. The top of the tree is the special All category, and every category you add sits somewhere under it. You create and edit groups in Setup, in the Data Category Setup page, by adding a group and then adding child categories one level at a time. Each group is a single dimension of classification, so a Products group answers what an article is about, while a Geography group answers where it applies. By default an org can have up to five active Category Groups, and each group can hold up to 100 categories arranged across as many as five hierarchy levels. Those ceilings are generous, but most well-run Knowledge bases use far fewer. A group has to be activated before authors can tag articles against it, and it must be linked to the Knowledge object so the category fields appear during authoring. Until both of those steps are done, the tree exists in Setup but does nothing for your articles.
Choosing the dimensions that matter
Picking your groups is the most consequential design decision in a Knowledge rollout. A common, durable pattern uses a Products group for the subject, a Geography group for regional applicability, and a Customer Type group for the audience. These three map cleanly onto how support teams and customers actually search. Salesforce documentation itself suggests Products, Geographical Areas, and Customer Types as a starting point. The temptation is to model every attribute as its own group, but each extra dimension is one more thing authors must remember to set, and tagging discipline drops fast as the count climbs. Keeping to three or four groups keeps the categorization panel readable and the data clean. Before you build anything, think about how users will filter results, who reaches the knowledge base, and which articles need to reach specific groups of people. Those answers tell you which dimensions earn a group and which are better handled as a custom field or a single flat category. Design the taxonomy with the people who use it, not alone at a whiteboard.
Hierarchy depth and category limits
Inside a group, Data Categories nest like folders. A Products group might have Hardware and Software at the first level, then Laptops and Desktops under Hardware, then specific model families below that. Salesforce allows up to five levels of depth and up to 100 categories per group, which is more than almost any program needs. Depth has a real cost. Every extra level is another click for a reader narrowing a browse tree and another decision for an author choosing where to tag. Three levels handles the vast majority of taxonomies cleanly, and going deeper rarely pays back the added navigation friction. Width has limits too. A category list that runs to dozens of siblings becomes hard to scan, so group related items under a parent rather than listing them flat. When you do hit a real ceiling, Salesforce support can raise the active-group count or the hierarchy-level limit on request, but treat that as a last resort. A taxonomy that needs the maximums is usually a taxonomy that should be simplified instead.
Visibility and securing articles
Category Groups are not only for organization. They also gate access through Data Category Visibility settings, which you assign by role, by permission set, or by profile. Visibility can be set to All categories, None, or Custom, where you select exactly which categories a user can see. The rule that trips people up is implicit inclusion. When a category is visible to a user, its parent and child categories come along automatically, so making a deep node visible quietly exposes the branch above and below it. Authors can only tag against, read, or remove categories their own visibility settings allow, and a group has to be active for any of this to apply. This is how one knowledge base serves several audiences from a single structure. Paying customers might get a whole branch of a group while a free tier sees only a sub-branch, and internal support sees everything. Because a misconfigured visibility rule can leak confidential content to the wrong audience, this is worth auditing on a schedule rather than setting once and forgetting.
Tagging articles against categories
Once a group is active and linked to Knowledge, authors categorize articles during authoring or editing. The article record shows the category fields for each linked group, and tagging is multi-select, so a single article can carry several categories from the same group. An article can be assigned up to eight categories from one category group, and since Spring 20 the total across all groups on a single article can reach 50, which lets you catalog content precisely. Articles do not have to be categorized at all, but an untagged article is hard to find and falls outside category-based reporting, so a tagging convention matters. You are not limited to the authoring UI either. The Knowledge API and Data Loader can read and write category assignments in bulk, which is how teams retag large libraries after a structural change. The key constraint to remember is that any tagging through the API still respects the author's Data Category Visibility, so an integration user can only set categories it is allowed to see.
Browse, search, and reporting
The structure you build powers every place users meet your content. In Lightning Knowledge, the category fields drive the sidebar filters agents use to narrow results inside a case. In Experience Cloud and Help Center sites, the same groups render as a browse tree so customers can drill from a top-level category down to the articles they need. Because both internal and external experiences read from one taxonomy, a clean group design improves findability for staff and customers at the same time. Reporting leans on the same dimension. You can filter Knowledge reports by Data Category to count articles per product, track average article age per region, or watch archive rates per audience. Without categorization those reports collapse into one undifferentiated bucket, which is why inconsistent tagging is the usual reason Knowledge analytics stop being useful at scale. The relationship runs in one direction. The Category Group defines the dimension, the categories define the values, and search, browse, and reports all consume what you have defined. Get the group right and everything downstream gets easier.
Evolving the taxonomy over time
Taxonomies are never finished. Products get added, regions get reorganized, and a group that fit two years ago starts to strain. Salesforce supports renaming categories, adding levels, and restructuring branches, but those changes ripple into already-tagged articles. When you merge or split categories, existing articles need re-tagging so they land in the right place, and that cleanup is routinely underestimated. Plan structural changes with a migration approach in mind: know which articles each change touches, decide how they will be retagged, and consider scripting the retag through the API or Data Loader rather than doing it by hand. Deactivating a group hides it from authoring without deleting the data, which is a safer first step than deleting outright. A few failure modes recur across orgs. Too many groups overwhelm authors and produce inconsistent tags. Too few collapse dimensions you actually need to filter on. And visibility misconfiguration, the quiet one, exposes content to the wrong audience. Each is avoidable with deliberate up-front design and a periodic review, which together keep the taxonomy honest as the content library grows.
Set up a Category Group for Knowledge articles
You configure a Category Group for Articles in Setup, then activate it and link it to Knowledge so authors can tag articles. Plan the dimensions and the tree before you start, because reshaping a live group means retagging existing articles.
- Open Data Category Setup
From Setup, enter Data Category in the Quick Find box and select Data Category Setup. This is the home for every Category Group in the org.
- Create the group
Add a new Category Group, giving it a Group Name and a user-facing Label. Pick a name that names one clean dimension, such as Products or Geography.
- Build the category tree
Click the group name and add Data Categories under the All node, nesting child categories to mirror how users will browse. Keep the tree to around three levels.
- Activate and link to Knowledge
Activate the group, then assign it to the Knowledge object so the category fields appear during authoring. Only active, linked groups affect articles.
- Set Data Category Visibility
Configure visibility by role, profile, or permission set as All, None, or Custom, remembering that a visible category implicitly includes its parents and children.
Up to five groups can be active at once; most programs use three or four to keep tagging consistent.
Each group holds up to 100 Data Categories across up to five hierarchy levels.
Authors can tag up to eight categories from one group, and since Spring 20 up to 50 categories across all groups on an article.
Set per role, profile, or permission set to All, None, or Custom selected categories.
- A group does nothing until it is both activated and linked to the Knowledge object.
- Making a deep category visible silently exposes its parent and child categories, so audit visibility before launch.
- Renaming, merging, or splitting categories forces re-tagging of articles already assigned to them.
- Articles can be left uncategorized, but uncategorized articles drop out of browse filters and category reports.
Prefer this walkthrough as its own page? How to Category Group for Articles in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Work with Data CategoriesSalesforce
- Create and Modify Category GroupsSalesforce
Straight from the source - Salesforce's reference material on Category Group for Articles.
- Data Category VisibilitySalesforce
- Salesforce Knowledge Data Categories Best PracticesSalesforce
Hands-on resources to go deeper on Category Group 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 does a Category Group for Articles do in Salesforce Knowledge?
Q2. Besides browsing, what other purpose does a Category Group for Articles serve?
Q3. Can the same Knowledge article be tagged in more than one Category Group for Articles?
Discussion
Loading discussion…