Knowledge Management
Knowledge as a product, not a folder
Lightning Knowledge stores articles as records of an article type (which defines fields and layout), organized by data categories (the taxonomy used for navigation and visibility). Data categories control who sees what through data category visibility on profiles and channel visibility per channel (internal app, customer/Experience Cloud site, public site, partner). Article lifecycle moves draft → review/approval → published → archived; approvals are enforced through the article type's workflow settings.
Name the mechanics: versioning (editing a published article produces a version), promotion of search terms to improve findability, suggested articles surfaced on cases, Knowledge search in the console, and translations for multi-language orgs. Licensing matters: a Knowledge-Only user can read articles without consuming a full service license, but does not author.
Traps: confusing data categories with topics or record types; assuming publishing is free-form when an approval process is configured; assuming an article visible internally is visible to customers - that is a separate channel setting; forgetting that archiving removes an article from search results.
Rule of thumb: design the taxonomy from the customer's vocabulary, not the org chart, and use one article type per distinct content structure (how-to, troubleshooting, policy) so fields stay meaningful.
Worked example: Customers can't find the refund policy article. It is published with the correct data category. Diagnosis: channel visibility for the customer-facing channel was never enabled, so the article exists only for internal users. Fixing visibility, not rewriting, resolves it.