Enhanced Knowledge Settings
Enhanced Knowledge Settings is a transitional name used in some Salesforce documentation for the configuration options available specifically with the Lightning Knowledge feature set, as distinguished from the older Classic Knowledge settings.
Definition
Enhanced Knowledge Settings is a transitional name used in some Salesforce documentation for the configuration options available specifically with the Lightning Knowledge feature set, as distinguished from the older Classic Knowledge settings. The phrase covers options like rich text body field configuration, channel selection per record type, the modern article search and ranking model, and the per-record-type page layouts that Lightning Knowledge introduced. The term appears mainly in Help articles discussing the differences between the legacy and modern Knowledge stacks.
Enhanced Knowledge Settings is closely related to and often used interchangeably with Knowledge Settings (the broader Setup page). The Enhanced qualifier was added during the period when both Classic and Lightning Knowledge coexisted in production orgs and admins needed clear documentation distinguishing the two configuration models. In current documentation, the term is fading; most modern Salesforce Help articles use Knowledge Settings or Lightning Knowledge Settings without the Enhanced qualifier. The functional meaning is the same: org-wide configuration for the Lightning Knowledge feature.
How Enhanced Knowledge Settings differentiated Lightning Knowledge config from Classic
Why Enhanced Knowledge Settings as a term existed
When Salesforce launched Lightning Knowledge in 2017, the configuration options on the Setup page expanded to cover the new data model: rich text body fields per record type, channel selection per article, multilingual workflow, search ranking algorithm choice. The older Classic Knowledge settings persisted alongside the new ones during the transition period. Documentation used the Enhanced qualifier to make clear which configuration applied to Lightning Knowledge versus Classic. The dual configuration phase lasted roughly 3 to 4 years; now that Classic Knowledge is fully retired in new orgs, the Enhanced qualifier is fading from current documentation.
Key Enhanced configuration options
The settings introduced with Lightning Knowledge include: Per-record-type page layouts (different layouts for FAQ, How-To, Known Issue, each with its own field set). Channel checkboxes per article (Internal App, Customer, Partner, Public). Rich text body fields per record type (the article body is rich text per record type, not one global body). Article voting per record type (different feedback mechanisms per article type). Search ranking model (Lightning uses a different search ranking algorithm than Classic). Together these options shape how Lightning Knowledge behaves and how it differs from the legacy stack.
Per-record-type page layouts
The biggest configuration shift in Lightning Knowledge is the per-record-type page layout model. Classic Knowledge used a single layout per __kav object. Lightning Knowledge has record types on KnowledgeArticleVersion, and each record type can have its own page layout, field set, and Article Actions. An FAQ layout might focus on Question and Answer fields; a How-To layout might focus on Problem and Steps fields. The per-record-type customization is what makes Lightning Knowledge flexible without forcing a one-size-fits-all article template.
Channel checkboxes per record type
Lightning Knowledge introduced explicit channel checkboxes on each article: IsVisibleInApp, IsVisibleInCsp, IsVisibleInPrm, IsVisibleInPkb. The checkboxes are per-article and per-record-type defaults can be configured. This is what controls article visibility across Internal App, Customer Portal, Partner Portal, and Public Knowledge Base. The granular control is what makes the same Knowledge content reusable across audiences without separate article duplication.
Search ranking algorithm and synonym handling
Lightning Knowledge uses a refreshed search ranking algorithm compared to Classic. The algorithm considers article view counts, attach rates, recency, and category relevance. Synonym Groups apply to both Classic and Lightning, but the integration with the ranking model is tighter in Lightning. The Enhanced Knowledge Settings docs called out these search improvements as a Lightning differentiator. Modern documentation just describes them as how Salesforce Knowledge search works without the comparison framing.
Multilingual configuration in Enhanced Settings
Enabling Multiple Languages in the Knowledge Settings page unlocks the Lightning Knowledge translation workflow. The setting was sometimes called out as part of Enhanced Knowledge Settings because the translation flow in Lightning differs meaningfully from Classic. Each article has a master version with explicit translations linked through KnowledgeArticleId. The master republishing marks translations outdated. Translators work through a dedicated translation queue or through the Knowledge Translation API for vendor integration.
Migration framing: how to think about the term today
For practical purposes, Enhanced Knowledge Settings is a near-synonym for Knowledge Settings as it applies to Lightning Knowledge. New deployments configure the standard Knowledge Settings page and get the Lightning behavior automatically. Existing Classic deployments encountering the Enhanced qualifier in documentation should map it to "the configuration that applies when Lightning Knowledge is enabled". The dual-stack framing is fading as Classic Knowledge becomes a legacy artifact rather than a current option.
Configuring the Lightning Knowledge options Enhanced Settings docs covered
Configuring the options that the Enhanced Knowledge Settings docs referred to means configuring the standard Knowledge Settings page after enabling Lightning Knowledge. The workflow is the same as configuring Lightning Knowledge in general.
- Confirm Lightning Knowledge is enabled
Setup, Knowledge Settings, Enable Lightning Knowledge. The Enhanced options become available after this toggle.
- Configure per-record-type page layouts
Setup, Object Manager, Knowledge, Record Types. For each record type (FAQ, How-To, Known Issue), define a page layout with the appropriate field set and Article Actions.
- Set default channel checkboxes per record type
On each record type's page layout, configure the default values for IsVisibleInApp, IsVisibleInCsp, IsVisibleInPrm, IsVisibleInPkb. Authors can override per article.
- Configure rich text body fields per record type
Add a rich text Body field to each record type's page layout. The field is per-record-type, so FAQ might have a Question and Answer rich text field, How-To might have Problem and Steps.
- Enable Multiple Languages if multilingual
Knowledge Settings, Enable Multiple Languages. Add the secondary languages. Each adds a translation lifecycle to articles.
- Configure Article Voting if needed
Knowledge Settings, Enable Article Voting. Configure public voting and internal voting separately.
- Set up Synonym Groups
Setup, Search, Synonym Groups. Build the synonym sets that improve search recall for internal terminology.
- Document the configuration for editors
Publish a Knowledge Article or training note explaining the per-record-type configuration so authors can use it correctly.
Different layouts per article variant, with distinct field sets, Article Actions, and rich text fields.
Defaults for IsVisibleInApp, IsVisibleInCsp, IsVisibleInPrm, IsVisibleInPkb configured at the record type level.
Article body fields are rich text per record type, not one global body.
Translation workflow unlocked through the Knowledge Settings page after Lightning Knowledge is enabled.
The Lightning search ranking model with view-count and attach-rate weighting.
Per-record-type voting configuration for helpful/not-helpful feedback.
- Enhanced Knowledge Settings is mostly a documentation term, not a separate Setup page. The configuration lives in Knowledge Settings and the per-record-type page layouts.
- Per-record-type page layouts require deliberate planning. Cap record types at 4 to 5; more usually means a single record type with conditional fields would have been simpler.
- Channel checkbox defaults at the record type level are overridable per article. Authors who forget to check the right channel get unpublished or invisible articles.
- Multilingual articles do not auto-translate when the master republishes. Translations get marked outdated; translators must update them manually.
- Synonym Groups apply globally to the org. A synonym that helps the support team may confuse the sales team. Build synonyms carefully.
Trust & references
Straight from the source - Salesforce's reference material on Enhanced Knowledge Settings.
- Knowledge SettingsSalesforce Help
- Lightning Knowledge OverviewSalesforce Help
- Set Up Lightning KnowledgeSalesforce Help
Hands-on resources to go deeper on Enhanced Knowledge Settings.
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 business function does Enhanced Knowledge Settings primarily support?
Q2. How does Enhanced Knowledge Settings help support agents be more productive?
Q3. Which Salesforce Cloud includes Enhanced Knowledge Settings as a key feature?
Discussion
Loading discussion…