A support team at a telco called me in because their knowledge base "had a permissions bug." The symptom: a content editor on the marketing team had published a how-to article, customers could see it through the self-service portal, but the Tier 1 agents handling the same product over the phone could not find it in the Service Console. Same article, same data categories, two audiences, and only one of them could read it. The team assumed something was broken.
Nothing was broken. The article had been published to the customer channel but not the internal one, and even if it had, the agents' profile did not have visibility to the data category the article was tagged with. Both conditions have to be satisfied before anyone sees an article, and the two conditions live in completely different places in Setup. This is the single most common source of "Knowledge doesn't work" tickets I see, and almost every time it traces back to people treating article visibility as one switch when it is actually two.
If you are standing up Salesforce Knowledge, the structure decisions are easy and the visibility decisions are where projects quietly go wrong. So that is where I want to spend the time, after a quick pass on how articles are shaped in the first place.
One object, many record types
Classic Knowledge gave you a separate sObject for every article type, which meant FAQs, troubleshooting guides, and policy documents were genuinely different objects with different APIs. Lightning Knowledge throws that away. Everything is now a single object, Knowledge__kav, and what used to be an "article type" is just a record type with its own page layout.
That sounds like a downgrade until you live with it. At the telco we ended up with four record types: a FAQ type with question and answer fields, a troubleshooting type carrying symptom, steps, resolution, and related-article fields, a product-info type holding plan name, price, speed, and promotion, and a policy type with a body plus effective and expiry dates. Each one gets its own layout, so a Tier 1 agent opening a troubleshooting article sees a clean "Steps" field, while a product article never shows steps because it does not need them. The record-type model makes this trivial; you are configuring layouts, not maintaining four objects.
A few structural facts are worth burning into memory before you commit. Enabling Lightning Knowledge is a one-way switch. Once it is on you cannot return to Classic, and there is no tool that auto-converts old article types into record types, so any org with an existing Classic base needs a hand-built migration and a serious sandbox dry run before anyone flips that toggle. The other one that bites people: if you create a record type but forget to assign its page layout per profile, authors fall back to the default Knowledge layout and simply do not see the fields you added. The policy author at the telco couldn't find the expiry-date field for exactly this reason, and it looked like data loss when it was just an unassigned layout.
Channel visibility: what the article exposes
The first half of visibility lives on the article itself. Salesforce defines four channels, and each article version carries a checkbox for each one. The internal app channel covers your Salesforce users in the Service Console. The customer channel covers Experience Cloud users on a Customer Community license hitting a customer portal. The partner channel is the equivalent for partner-community users. And the public knowledge base channel covers anonymous guest users on a public Experience Cloud site.
Ticking a channel is how an author declares "this content is intended for that audience." Tick internal app plus customer and the article is eligible for both agents and logged-in customers; leave public unticked and no anonymous visitor will ever render it, regardless of anything else in the org. This is also where the telco's original bug started: the marketing editor had ticked customer and never ticked internal app, so the agents were excluded by design they didn't know existed.
The decision I push clients on here is whether one article serves multiple audiences or whether you need separate articles per channel. A hospital group I worked with had a "general check-up procedure" article that absolutely could not be one record with three channels ticked. The internal version listed internal drug codes, specialist contacts, and internal pricing. The patient version was a trimmed walkthrough of where to go and how long to wait, with none of that. The public-website version was essentially marketing plus a booking link. Three audiences, three genuinely different bodies, so three separate articles, each tagged to its own audience category. The rule of thumb: if the content is generic enough to share, one article with multiple channels is fine; the moment any audience needs content the others must not see, split it, because a shared body is a leak waiting to happen.
Data-category visibility: what the user is allowed to find
The second half of visibility lives on the user, not the article, and this is the piece people forget exists. Data categories are your taxonomy. You define data category groups, which are classification axes, each with a hierarchy of categories underneath. The telco ran a product-line group (internet splitting into fiber and ADSL, TV into IPTV and cable, plus mobile), a region group, and an audience group containing internal-agent, customer, and public. Articles get tagged with one or more categories per group. Worth knowing the ceilings before you design: an org can have at most five active data category groups, each group tops out at 100 categories and five levels deep, and a single article can be tagged across at most eight groups.
Data category visibility settings then decide which profiles, roles, or permission sets can see which categories. Give the Tier 1 Agent profile visibility to the internal-agent and customer audience categories and those agents can find every article tagged with them; give the Customer Community profile visibility to only the customer and public categories and that is the boundary of what those users can ever surface. This is genuinely separate from channels. Channel visibility is set on the article and answers "who is this for"; data-category visibility is set on the user and answers "what is this user allowed to find."
The critical part is that the two are ANDed together, not OR'd. An article must tick the channel the user is coming through and be tagged with a category that user's profile can see. Miss either and the article vanishes for that person. Profile has visibility to everything but the article didn't tick the customer channel? Invisible on the portal. Article ticked the customer channel but the customer profile lacks visibility to the article's category? Still invisible. At the telco both halves were misaligned at once, which is why the article looked so haunted.
One gotcha that generates support calls on its own: data-category visibility has a default ("All", applied to any profile you haven't explicitly overridden) and a custom per-profile setting. Teams set a profile to a restricted custom visibility, forget to actually save it, and the profile silently keeps falling back to the "All" default. Then someone reports that a profile is "still seeing articles it shouldn't," and the fix is simply to confirm the save and verify by logging in as that user.
Knowledge has no real OWD, so guard the guest user
Here is the structural fact that should change how you think about the whole feature: the org-wide default for Knowledge is always Public Read, and you cannot restrict it at the record level. Data-category visibility and channel visibility are your access control. They are not refinements on top of sharing; they are the sharing model.
That makes the guest-user profile the most dangerous object in the setup. If your knowledge OWD is Public Read (which it must be for self-service to work) and the guest user profile has data-category visibility set to "All", a curious anonymous visitor can potentially reach an internal-only article by guessing its URL, even though no public channel was ever ticked through the normal path. The hospital group's nightmare scenario was exactly this on the content side: an internal version with pricing and clinical detail accidentally copied into a public article, published, indexed by Google, and now public protected health information. The defenses are layered and worth specifying up front: restrict the guest-user profile's data-category visibility to the public audience only, split your authoring roles so the internal content editors and the public content editors have non-overlapping category visibility, and for high-stakes orgs add a validation rule that blocks publishing to the public channel when the body contains sensitive keywords, plus a mandatory admin review before anything goes public. Then actually test it: open an internal article's URL in an incognito window as an anonymous user and confirm you get "article not found."
While you are in the permissions layer, one quiet failure mode catches almost every team once. A user can have full create and edit permissions on Knowledge and still open the Knowledge tab to a blank screen because the "Knowledge User" license checkbox was never enabled on their permission set or user record. The error is not helpful, so people burn an afternoon on it. Check that box first whenever Knowledge "doesn't load" for a specific user.
The principle I leave clients with is to stop thinking of Knowledge visibility as a single permission and start thinking of it as two gates in series. The article decides which channels it is willing to appear in, the user's profile decides which categories it is allowed to find, and a reader only ever sees an article when both gates open at once. Design both deliberately, lock down the guest user as if it were hostile, and most of the "Knowledge is broken" tickets simply never get filed.
Implementing or optimizing Service Cloud? Our Salesforce team runs discovery, designs the case process, and configures Service Cloud, Omni-Channel, and Knowledge on production engagements. Get in touch ->
See our full platform services for the stack we cover.
