Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

The short version: Lightning Knowledge is one object, Knowledge__kav, where record types replace the old article types and every edit creates a new version. An article has a stable article record underneath it and a stream of versions on top, each with a publish status of Draft, Online or Archived. Almost everything confusing about Knowledge comes from forgetting that you are always looking at a version, not an article.

Turn it on once, and carefully

Enabling Lightning Knowledge is a one-way move. There is no supported path back to Classic Knowledge with its separate article type objects, and the Classic migration is a project rather than a checkbox.

Users who author or manage articles need the Knowledge User checkbox on their user record, which is separate from permissions. A user with every Knowledge permission set and no Knowledge User checkbox still cannot do the job, and the error message is not helpful about why.

Record types instead of article types

In Classic, each article type was its own object with its own fields. In Lightning, everything is Knowledge__kav and you separate content shapes with record types and page layouts.

This is better, and it tempts people into too many record types. A record type per department is usually wrong. Split by the shape of the content, not by who owns it: an FAQ with a question and an answer is genuinely different from a troubleshooting procedure with symptoms, cause and steps. Ownership belongs on a field or a data category.

The version model

Every article has a stable identifier that survives versions, and each version carries its own publish status and version number. The useful fields:

  • KnowledgeArticleId is the article itself, constant across every version and language.
  • PublishStatus is Draft, Online or Archived for that version.
  • VersionNumber increments as versions are created.
  • IsLatestVersion marks the most recent version of the article.
  • Language identifies the translation.

An article can have exactly one Online version at a time. Editing a published article creates a new draft alongside it, the published version stays live while the draft is worked on, and publishing the draft replaces it. The old online version becomes archived, not deleted.

SELECT Id, KnowledgeArticleId, Title, VersionNumber, PublishStatus, Language
FROM Knowledge__kav
WHERE PublishStatus = 'Online' AND Language = 'en_US'
ORDER BY LastPublishedDate DESC

Draft, Online, Archived

Draft is being written. Only users with authoring access see it. A draft is invisible to agents searching the knowledge sidebar, which surprises authors who expect to find their own work.

Online is published and visible to whoever the channels and data categories permit.

Archived is retired but retained. Archiving is the right way to retire content because the article stays queryable and reportable. Deleting loses the history, including which cases attached it.

Channels

Each version has channel checkboxes deciding where it can appear: the internal app, a customer community, a partner community, and a public knowledge base. These are independent of data categories and independent of sharing.

An article published with only the internal channel ticked is invisible in a community no matter what else is configured, and this is the second most common cause of “the customer cannot see the article”. The first is data categories.

Approvals before publishing

Knowledge supports approval processes on the draft version, and any organisation with more than a handful of authors should use one. Without it, publishing is a button anybody with the permission can press, and the first time a half-written internal note appears on a public site you will wish you had spent the afternoon on an approval process.

What to set up first

In order: enable Knowledge, assign the Knowledge User licence and permissions, define the record types and their layouts, build the data category structure, then set the default data category visibility before anybody writes anything. Getting the category structure right early matters more than the rest, because re-categorising a thousand published articles later is manual work.

Frequently asked

Why can an agent not see an article they just published? Check the language. A version in a language the user does not have in their knowledge settings will not appear in their search results even though the record exists.

Can I report on article usage? Yes. Article view and vote statistics exist as their own reportable data, and the link between a case and an attached article is reportable too. Attachment rate to cases is the more useful number.

Do I need a separate licence for Knowledge? Read access is included with Service Cloud licences. Creating and managing articles requires the Knowledge User setting, and community access depends on the community licence type.