Who Can Read a Knowledge Article? Data Categories, Standard Sharing and Channels

Module 5 of 8 in the chapter Files, Folders, Reports and Other Data, chapter 12 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: Knowledge articles are records, so why doesn’t the sharing you built for accounts and cases decide who reads them, and what does?

Knowledge is the shelf of articles your support team writes: how to reset a device, what the return policy says, what to do when an order is late. Support reps read them while they work a case. Customers read some of them on a help site. And some are for the team only.

So who reads which article? For years the answer was simple, and it’s the one in chapter 5 as way 15: data categories, not sharing. That’s still the default. But it isn’t the only answer any more, and an architect has to know which one the org is using.

The default: data categories

Here’s Salesforce: “Category group visibility settings determine who can access articles and questions. Although they are standard objects, articles and questions do not have organization-wide defaults, sharing rules, or manual record sharing” (How Category Visibility Differs from Other Salesforce Models (opens in a new tab), Salesforce Help, checked 2026-11-07).

Each article is tagged with categories, in groups. A Geography group might hold continents, then countries, then cities. Then each user is given categories they can see. “Data category visibility can be set with roles, permission sets, permission set groups, or profiles,” and for each group it’s one of three: “All Categories,” “None,” or “Custom: Selected categories are visible” (Data Category Visibility (opens in a new tab), Salesforce Help, checked 2026-11-07).

Four rules from that page are worth reading slowly.

Seeing one category sees its family. “Setting a category as visible makes that category and its entire directly related family line—ancestors, immediate parent, primary children, other descendants—visible to users.” Salesforce’s example: give someone France, and they see articles classified with Europe, France and every French city, but nothing under Asia.

An article needs one category from every group on it. Users see an article if they “can see at least one category per category group on the article.” An article tagged California and Ohio in Geography, and Desktop in Products, needs Ohio or California, and Desktop.

The sources add up. “If data category visibility is defined with roles, permission sets, and profiles, Salesforce uses a logical OR between the definitions.” That’s the same as everywhere else in this course: access adds up.

The roles follow the hierarchy, downward. “Child roles inherit their parent role’s settings,” and you can reduce a child role’s visibility “but you can’t increase it to be greater than that of the parent role.” And a trap for sites: “Because high-volume portal users don’t have roles, you must designate visibility settings by permission set or profile before these users can view categorized articles and questions.”

And one more, about the first day. “If role, permission set, or profile data category visibility hasn’t been set up, all users can see all data categories.” The moment you set it up, users with nothing assigned “only see uncategorized articles and questions unless you make the associated categories visible by default” (Data Category Visibility). So data categories start open, and they close the day you configure them. Plan that day.

Here’s what’s changed. “Since the Summer ‘20 release, standard Salesforce sharing for Lightning Knowledge is available. Switching to standard sharing changes how you work with data categories and how users can access Knowledge articles” (Data Category Visibility).

Turn it on in Knowledge Settings, with “Use standard Salesforce sharing,” and articles get what other records have: “organization-wide defaults, owner-based sharing, and criteria-based rules.” Out of the box, “the knowledge object uses Public Read/Write for internal users and Private for external access” (Choose the Sharing or Access Model for Lightning Knowledge (opens in a new tab), Salesforce Help, checked 2026-11-07).

And the data categories stay, with a new job. “When you use standard sharing, data categories no longer control record access. Your knowledge base continues to use data categories to classify articles” (same page).

Click to enlarge

Standard sharing isn’t all of sharing, though. From Sharing Considerations for Lightning Knowledge (opens in a new tab) (Salesforce Help, checked 2026-11-07):

Two sets are missing. “The following Sharing features aren’t available for Knowledge”: “Manual sharing” and “Apex sharing.” So Set 3’s hand tools and Set 5’s code don’t reach articles.
Sharing works on the version. “Sharing works at the level of the article version (the Knowledge__kav object) and not the primary article.” A rule can give a rep one version and not another, and “changing the value in a record between versions can change the result of a sharing rule.”
Authors need write access. “Setting the organization-wide default to Public Read Only prevents non-owners from performing authoring actions such as editing or restoring archived articles.”
Translators need both versions. “If the sharing for a primary-language article is set to Private, it can prevent translators from accessing the primary-language articles.”
View All Records doesn’t help. “Currently, object-level View All Records and Modify All Records don’t grant more access.”

Whichever model: the other locks

Some locks don’t care which model the org uses.

Object and app permissions come first. “Knowledge object permissions to Create, Read, Edit, and Delete articles, granted via profile permissions, control baseline access. Sharing settings refine access, but they can’t give access to articles the user can’t otherwise view or edit.” And “app permissions for Knowledge, such as View Draft Articles and View Archived Articles, are enforced regardless of sharing.” By default, “a user can view only published articles” (Sharing Considerations for Lightning Knowledge).

Channels say which audience. Every article carries four checkboxes. “To control which audiences can view an article, add these fields to the page layout: Visible in Internal App; Visible to Customer; Visible to Partner; and Visible in Public Knowledge base” (Page Layout Considerations for Lightning Knowledge (opens in a new tab), Salesforce Help, checked 2026-11-07).

Click to enlarge

The channel is the one that gets an article outside. A rep ticks Visible in Public Knowledge Base, the article is published, and it’s in front of anyone who visits the site. So the channel checkboxes are a security decision, made one article at a time, usually by someone who isn’t thinking about security. Who can tick that box, and who approves it, matters more than the category tree. Chapter 14 covers sites and guest users.

Test knowledge. Know that by default Knowledge articles have no org-wide defaults, sharing rules or manual sharing, and that data category visibility comes from role, permission set or profile. Know that a visible category brings its whole family line, that an article needs one visible category from each of its groups, and that a child role can’t see more than its parent. Know that high-volume site users have no role, so they need a permission set or profile. And know that Lightning Knowledge can switch to standard sharing, without manual or Apex sharing. A likely area, not a known question.

What an architect decides here

Which model the org uses: data categories or standard sharing, and why.
With data categories: the category groups and how they map to the role hierarchy; what’s visible by default; and the day visibility is first switched on.
With standard sharing: the org-wide defaults inside and outside, the rules, and whether authors and translators still have the access they need.
Who can tick the channel boxes, especially Visible in Public Knowledge Base, and whether publishing to customers or the public needs an approval.
Who holds View Draft Articles and View Archived Articles.
For site users with no role, which permission set or profile gives them categories.

Beyond the exam: what AI changes. Knowledge is the first thing most service agents are pointed at: answer the customer from the articles. So the article locks become the agent’s locks. If an internal-only article is visible to the agent’s user, the agent can quote it to a customer. Before an agent goes live, check which channel and which categories its user can see, and make sure they match the audience it answers. Chapter 20 covers agents.

Explore

How Category Visibility Differs from Other Salesforce Models (opens in a new tab), Salesforce Help (checked 2026-11-07)
Data Category Visibility (opens in a new tab), Salesforce Help (checked 2026-11-07)
Choose the Sharing or Access Model for Lightning Knowledge (opens in a new tab), Salesforce Help (checked 2026-11-07)
Sharing Considerations for Lightning Knowledge (opens in a new tab), Salesforce Help (checked 2026-11-07)
Page Layout Considerations for Lightning Knowledge (opens in a new tab), Salesforce Help (checked 2026-11-07)