Knowledge Data Categories and Article Visibility

Why This Topic Matters

Salesforce Knowledge is a core component of the Advanced Cloud Applications section of the Salesforce Advanced Administrator exam, and data categories are the backbone of how a knowledge base is organized and secured. Exam questions in this area test whether you can design a knowledge base that is easy to navigate, surfaces the right articles to the right people, and keeps sensitive content away from users who should not see it. In the real world, a poorly designed category structure leads to agents who cannot find answers, customers who see internal-only content, and admins who have to rebuild hierarchies from scratch. Understanding data categories and visibility is therefore both an exam skill and a practical administration skill.

What Are Data Categories?

Data categories are a classification system for Salesforce Knowledge articles. They are organized into data category groups, and each group contains a hierarchy of categories. Think of a category group as a dimension along which you classify articles, and the categories inside it as the actual values.

Common examples of category groups include:
- Products (for example Hardware > Laptops > Model X)
- Geography or Region (for example EMEA > Germany)
- Audience or Customer Tier (for example Gold, Silver, Bronze)
- Topic (for example Billing, Troubleshooting, How-To)

Data categories serve two primary purposes:
1. Classification and navigation - they let users filter and browse articles in the Knowledge component, the Knowledge tab, Experience Cloud sites, and search.
2. Access control - through data category visibility, they control which categorized articles a user is allowed to see.

Key Limits to Remember

Exam questions sometimes test limits. Commit these to memory and verify them against current Salesforce Help before your exam:
- Up to 5 category groups per org, with up to 3 active at one time.
- Up to 100 categories per category group.
- Category hierarchies can be up to 5 levels deep.
- An article can be classified with up to 8 categories per category group.
- Category groups must be activated before users can see them; inactive groups are visible only to administrators in Setup.

How Data Category Groups Work

Category groups are created in Setup under Data Category Setup. Each group has a unique name, a status (Active or Inactive), and a tree of categories that you build by adding child, sibling, and parent categories. Important behaviors include:

- Group assignment: A category group must be assigned to the Salesforce Knowledge object before it can be used for articles. Historically, groups could also be assigned to Answers and Chatter Answers, but Knowledge is the relevant object for the modern exam.
- Activation: A new category group is created in an inactive state so that you can build and review the hierarchy before exposing it. Once activated, it becomes available for categorizing articles and for visibility settings.
- Reordering and restructuring: You can drag categories to new positions in the hierarchy. Reorganizing the hierarchy can affect which articles are visible to users, because visibility is inherited through the tree.
- Deletion: Deleting a category removes that classification from all articles that used it. Deleted category groups are held for a limited time (typically 15 days) and can be restored before they are permanently removed, which is a useful safety net.
- Translations: Category names can be translated via the Translation Workbench so that users in different languages see localized labels.

How Articles Are Categorized

Authors apply data categories when creating or editing an article, choosing one or more categories from each active category group. A single article can carry categories from multiple groups at once (for example Product = Laptops AND Region = EMEA). Categories are typically inherited by article translations and carried across versions when an article is republished, though authors can adjust them.

A critical rule: an article that has no categories assigned in a particular category group is visible to all users who otherwise have access to the article, regardless of their data category visibility settings for that group. Data category visibility only restricts articles that are actually categorized. If an exam scenario describes a sensitive article that everyone can see, check whether it was ever categorized.

How Data Category Visibility Works

Data category visibility determines which categorized articles a user can see. It is configured on profiles and permission sets, which is the modern recommended approach (older orgs may still have role-based settings). For each active category group, you choose one of three visibility options:

- All Categories - the user can see articles in every category of the group.
- None - the user cannot see any categorized article in the group (uncategorized articles remain visible).
- Custom - you select specific categories the user can see.

With Custom visibility, remember the inheritance rule: granting visibility to a category also grants visibility to that category's ancestors (parents) and all of its descendants (children), but not its siblings. For example, if a profile is granted visibility to Europe > Germany, the user can see articles categorized as Germany, articles categorized as Europe (the parent), and anything under Germany, but not articles categorized as France.

Default Visibility: Each category group has a default data category visibility setting that applies to users whose profile or permission set does not specify a setting for that group. New category groups default to All Categories, so if you want to lock content down by default you must change the group default to None or Custom and then grant access selectively.

Permission Sets vs. Profiles: Data category visibility is additive. If a user has a profile with limited visibility and a permission set that grants additional categories, the user sees the union of both. This makes permission sets the flexible tool for granting extra access to specific groups of agents without creating new profiles.

How Visibility Combines With Other Security Layers

Data category visibility is only one layer. To actually read an article, a user must also pass through these controls, and exam scenarios often mix them up deliberately:

1. Knowledge User license / feature access - internal users need the Knowledge User checkbox (or appropriate permission set license) to author or manage articles; reading may require Knowledge access depending on configuration.
2. Object and field permissions - Read on the Knowledge object, plus field-level security.
3. Record types - in Lightning Knowledge, record types replace legacy article types; profile record type access controls which article types a user can create or view.
4. Channels - each article is published to one or more channels: Internal App, Customer (Experience Cloud customer users), Partner (partner users), and Public Knowledge Base (guest users). Channels determine audience, not category access. An article not published to the Customer channel will never appear to customers no matter how categories are configured.
5. Standard sharing in Lightning Knowledge - Lightning Knowledge offers an option to use standard Salesforce sharing (org-wide defaults, role hierarchy, sharing rules, manual sharing) for articles instead of data category visibility. When standard sharing is enabled, data categories still classify articles and drive navigation and filtering, but they no longer control access. You use one access model or the other, not both.
6. Experience Cloud and guest users - for public help centers, data category visibility is set on the guest user profile of the site. Data categories can also be mapped to Experience Cloud topics to create a navigable help center.

Data Category Mapping for Cases

Advanced Administrators should also know Data Category Mapping, found in Knowledge Settings. It maps a picklist field on the Case object (for example a Product picklist) to a data category group so that article suggestions and Knowledge search on a case automatically filter by the case's category. This improves agent productivity and is a frequent exam scenario phrased as 'agents want suggested articles that match the product on the case'.

Reporting and Analytics

Data categories appear in Knowledge reports, allowing managers to see article usage, ratings, and case attachment rates by category. Knowing that categories are reportable helps you answer questions about measuring knowledge base effectiveness.

Design Best Practices

- Keep hierarchies shallow and intuitive; deep trees frustrate users and complicate visibility.
- Use separate category groups for independent dimensions (Product vs. Region) rather than cramming everything into one tree.
- Set the group default visibility deliberately before activating the group.
- Use permission sets for exceptions rather than proliferating profiles.
- Test visibility by logging in as representative users or using the visibility test features.
- Decide early whether you will secure articles with data category visibility or standard sharing, because switching later requires a redesign.

Exam Tips: Answering Questions on Knowledge Data Categories and Article Visibility

1. Identify what is really being asked: classification, navigation, or access. If the scenario says users should be able to filter or browse articles by product, the answer is a data category group. If it says certain users must not see certain articles, the answer involves data category visibility on profiles or permission sets (or standard sharing if the org uses it).

2. Distinguish channels from data categories. 'Customers should not see internal troubleshooting articles' is a channel question - do not publish to the Customer or Public Knowledge Base channel. 'Gold-tier customers should see premium articles but Silver customers should not' is a data category visibility question on the respective Experience Cloud profiles.

3. Remember uncategorized articles are visible to everyone. If a question describes an article leaking to users with None visibility, the likely cause is that the article was never categorized in that group.

4. Apply the inheritance rule carefully. Visibility to a child includes its ancestors and descendants but not siblings. When a question gives a hierarchy and asks what a user can see, trace up and down the tree, never sideways.

5. Know where visibility is configured. The correct answer will reference profiles and permission sets (and the category group default). Answers that suggest page layouts, field-level security, or validation rules for controlling article visibility are distractors.

6. Watch for the Lightning Knowledge sharing switch. If the scenario states the org uses standard Salesforce sharing for Knowledge, data category visibility settings will not restrict access, and the answer will involve org-wide defaults or sharing rules instead.

7. Remember default visibility defaults to All Categories. A common scenario: an admin creates a new restricted category group and everyone can still see everything. The fix is to change the group's default visibility to None and grant Custom visibility to the appropriate profiles or permission sets.

8. Case-to-article suggestions point to Data Category Mapping. Any scenario about automatically filtering suggested or searched articles based on a case field is answered by mapping that case picklist to a category group in Knowledge Settings.

9. Respect the limits. Questions may describe an org trying to create a sixth category group or a very deep hierarchy. Recall the limits (5 groups, 3 active, 100 categories per group, 5 levels deep, 8 categories per group per article) and pick the answer that redesigns within them.

10. Prefer permission sets for exceptions. If the scenario says a small subset of agents needs access to additional categories without changing everyone's profile, the best-practice answer is a permission set with Custom data category visibility.

11. Eliminate answers that mix up legacy and modern terminology. Lightning Knowledge uses record types, not article types; modern visibility is set on profiles and permission sets, not roles. Distractors often rely on outdated concepts.

12. Read for the word combination. Many correct answers require two actions, such as activating the category group AND setting visibility, or publishing to a channel AND granting category visibility. Choose the option that addresses every requirement in the scenario, not just the most obvious one.

Summary

Data category groups organize Knowledge articles along meaningful dimensions, and data category visibility - configured on profiles, permission sets, and group defaults - controls which categorized articles users can see, with access flowing to ancestors and descendants of a granted category. Channels define audiences, record types define article structure, and Lightning Knowledge's standard sharing offers an alternative access model. Master the distinctions between these layers, remember that uncategorized articles are always visible, and apply the inheritance and default-visibility rules precisely, and you will be well prepared for any Knowledge data category question on the Advanced Administrator exam.