Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
DictionaryLLightning Knowledge
ServiceIntermediate

Lightning Knowledge

Lightning Knowledge is the modern incarnation of Salesforce Knowledge built on the Lightning Experience platform.

§ 01

Definition

Lightning Knowledge is the modern incarnation of Salesforce Knowledge built on the Lightning Experience platform. It uses a single sObject, KnowledgeArticleVersion, with record types per article variant (FAQ, How-To, Known Issue), replacing the older Classic Knowledge model that used a separate __kav object per article type. Lightning Knowledge supports the same multilingual, multi-channel, lifecycle-driven publishing workflow as Classic but with a unified data model that simplifies development, integration, and search.

Lightning Knowledge is the supported path for new Service Cloud deployments. Classic Knowledge cannot be enabled in new orgs created after 2019 and is in maintenance mode for older orgs. Migration from Classic to Lightning is a one-way conversion: the platform consolidates the legacy __kav objects into KnowledgeArticleVersion with record types, and custom code referencing the legacy objects must be rewritten. Most current Service Cloud customers run Lightning Knowledge, and every new Trailhead module assumes the Lightning model.

§ 02

How Lightning Knowledge modernizes the knowledge-base data model

Why Lightning Knowledge replaced Classic Knowledge

Classic Knowledge used a separate sObject per article type: FAQ__kav, HowTo__kav, KnownIssue__kav. Each had its own fields, page layouts, validation rules, and Apex references. Maintaining five article types meant maintaining five schemas. Lightning Knowledge collapsed this into one sObject (KnowledgeArticleVersion) with record types, the same pattern used elsewhere on the Salesforce platform. The benefit is a unified data model: one schema, one set of integrations, one SOQL pattern. The migration cost is significant, which is why some legacy orgs still run Classic, but the architectural improvement is real.

KnowledgeArticleVersion: the single underlying object

Every Lightning Knowledge article is a row on KnowledgeArticleVersion. Record types differentiate article variants. The object has the standard publishing lifecycle fields (PublishStatus: Draft, Online, Archived), language fields (Language, MasterVersion), channel fields (IsVisibleInApp, IsVisibleInPkb, IsVisibleInCsp, IsVisibleInPrm), and content fields (Title, UrlName, Summary, plus rich text Body fields per record type). SOQL queries target KnowledgeArticleVersion with PublishStatus filters. SELECT Id, Title FROM KnowledgeArticleVersion WHERE PublishStatus = 'Online' AND Language = 'en_US' returns all live English articles.

Record types and per-type customization

Record types are the differentiator. A FAQ record type might have fields Title, Question, Answer, Category. A How-To record type might have Title, Problem, Steps (rich text), Outcome. Each record type has its own page layout and field set. Templates per record type drive the Help Center rendering, so customers see consistent FAQ-style cards for FAQs and step-by-step views for How-Tos. The record type strategy is the key design decision in any Lightning Knowledge rollout. Cap the record types at 4 to 5; more usually means a single record type with conditional fields would have been simpler.

Data categories and topic navigation

Data Categories are hierarchical groupings (Region: USA, Canada, EMEA; Product: Cloud, On-Premises, Mobile) used for both navigation and permission control. Each article gets tagged with one or more category values. Topics are a flat tagging mechanism used in Lightning Knowledge for navigation in Experience Cloud. Topics power related-articles and topic-catalog pages. Most modern orgs use both: categories for permission gating, topics for findability. The two systems coexist intentionally; they cover different use cases.

Multilingual: master and translations

Lightning Knowledge supports translations through the same KnowledgeArticleVersion object. The master article has Language = en_US (or the org's default). Translations are separate rows with Language = es, fr, ja, with a shared KnowledgeArticleId linking them. Each translation moves through its own Draft, Pending Translation, Published lifecycle. The master republishing marks translations outdated until a translator updates them. Salesforce can integrate with translation providers through the Knowledge Translation API or translations can be authored manually inside the org.

Channels: Internal, Customer, Partner, Public

Each article has four channel checkboxes: IsVisibleInApp (Internal App), IsVisibleInCsp (Customer Portal / Experience Cloud Help Center), IsVisibleInPrm (Partner Portal), IsVisibleInPkb (Public Knowledge Base, anonymous-readable, SEO-indexed by Google). Channels combine with sharing model and Data Category Visibility to determine the final audience. Misconfigured channels are the most common reason a published article does not appear where the team expected. Audit channel selection on every article before publishing.

Lightning Knowledge in the Service Console

Inside the Service Console, the Knowledge Component sits in the Utility Bar or on the case page. It runs an auto-suggest query against the case Subject and Description, ranks matching articles, and lets agents attach an article to the case with one click. The attachment increments view counts, feeds article ranking, and pushes the article into the customer's case feed. The integration is what makes Knowledge a deflection engine: agents who attach articles deflect customer follow-up calls.

§ 03

Enabling and configuring Lightning Knowledge

Enabling Lightning Knowledge is a one-way Setup action. Plan the record type strategy, data categories, and channel governance before flipping the switch.

  1. Enable Lightning Knowledge

    Setup, Knowledge Settings, Enable Lightning Knowledge. The action is irreversible in new orgs. Practice in a sandbox before flipping in production.

  2. Design and create record types

    Setup, Object Manager, Knowledge, Record Types. Create FAQ, How-To, Known Issue, Product Spec or similar. Limit to 4-5 record types; more is usually too many.

  3. Configure data category groups

    Setup, Data Categories. Build two groups: one for product or content category, one for audience or region. Build the hierarchy carefully; categories cannot be deleted if articles use them.

  4. Set Data Category Visibility on profiles

    For each profile that needs Knowledge access, configure Data Category Visibility explicitly. Default of All is rarely the right choice and leaks internal articles.

  5. Add the Knowledge component to the Service Console

    Lightning App Builder, edit the Service Console case page, drag Knowledge Component into the right rail. Configure auto-suggestion against case Subject and Description.

  6. Build page layouts per record type

    Each record type needs its own layout with the appropriate fields, Article Actions section, and Knowledge-specific publishers.

  7. Create and publish pilot articles

    Create 3-5 pilot articles across record types. Publish to the right channels. Confirm the articles appear in the agent console, the Help Center, and search results.

Key options
Enable Lightning Knowledgeremember

One-way toggle that activates the KnowledgeArticleVersion object and the Lightning Knowledge UI. Cannot be reversed in new orgs.

Record Typeremember

Differentiator per article variant (FAQ, How-To, Known Issue). Each gets its own page layout and field set.

Data Categoriesremember

Hierarchical grouping for navigation and permission. Up to 5 active category groups per org.

Topicsremember

Flat tagging mechanism used in Lightning for navigation and related-articles widgets.

Channel checkboxesremember

Per-article toggles for Internal App, Customer Portal, Partner Portal, Public Knowledge Base visibility.

Gotchas
  • Enabling Lightning Knowledge in a new org is one-way. The decision cannot be reversed. Practice in a sandbox first.
  • Classic Knowledge cannot be enabled in new orgs created after 2019. Existing Classic orgs are migrating; new orgs have no choice but Lightning.
  • Record types cannot be cleanly deleted once articles use them. Plan the record type model carefully before going to production.
  • Data Category Visibility is profile-based, not user-based. Permission sets do not grant data category visibility.
  • Channel checkboxes interact with sharing model and Data Category Visibility. Forgetting a channel is the most common reason an article appears missing from the Help Center.
§

Trust & references

Sources

Cross-checked against the following references.

Official documentation

Straight from the source - Salesforce's reference material on Lightning Knowledge.

Keep learning

Hands-on resources to go deeper on Lightning Knowledge.

Was this entry helpful?
Help us write better definitions. Quick reactions or detailed edit suggestions.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.

§

Test your knowledge

Q1. What is Lightning Knowledge?

Q2. How does Lightning Knowledge differ from Classic Knowledge?

Q3. Should new implementations use Lightning Knowledge?

§

Discussion

Loading…

Loading discussion…