Service Console and Knowledge Search

Lets talk about Service Console and Knowledge Search. How much do you know about it? What does it do? What features does it have? So glad you asked!


Recommendations as You Type

One of the great features of Service Console is the ability to have the Knowledge Sidebar recommend articles as a user types into the Case Subject. Unfortunately this feature is not available when migrating to Lightning and Lightning Knowledge. Salesforce documentation recommends the workaround of adding the Lightning Knowledge component. Doing so you lose the coupling between the Case Subject and search terms. We alleviated this by writing two simple Lightning Web Components and incorporating the pub-sub model to handle communication between components. Search terms were gathered in the form of dependent picklist values, which were passed to a simple sibling component that would construct a SOSL search and display the relevant articles.


Finding Relevant Articles

The Classic Knowledge Sidebar would only recommend articles that had been updated within the past 30 days, so it wasn’t great at finding the most relevant articles. I think we can do better. Constructing your own search string has the benefit of greater control over how the search is performed.


The Inner Workings of “Search”

First let’s talk about Categories and the inner working of search. Salesforce uses two open source technologies Apache Lucene and Elasticsearch, which they have likely customized. Both work in a similar fashion, they build an index that matches search terms to articles. For arguments sake let’s say Lucene and Elasticsearch are also similar to how Google Search works. When we build Data Categories in Knowledge, we are building an additional index. This additional index of categories is static, you tag articles with data categories and articles are recommended based on matches, no learning.



Conversely with the Lucene or Google based searched users are presented a list of likely articles and the system builds a ranking system based on how many times users select a given article. The ranking isn’t this simple, it also takes into consideration how many words occur between two search terms in the articles that are indexed. The name for this in search technology is called distance. Subsequent results are weighted by this ranking. It’s expected that with time these rankings will improve search recommendations. When we build too many data categories or a rich data category hierarchy we are competing or negating this ranking system. As you build out your Knowledge be mindful that the system will learn which articles should be recommended and don’t burden the system with too many data categories that can overpower recommendations based on past results. Plus it’s a lot of work to accurately maintain a category system like a library.


Run the Experiment

To find the right balance build out Knowledge articles in a full copy sandbox and perform some searches with some expected outcomes. Measure success and determine how well the system begins to learn what articles to recommend. Now gradually add Data Categories and continue to measure outcomes and adjust search terms to determine if the system is recommending the best articles.



For more information and helpful resources, visit the links below.

Trailhead for KB search for Lightning: trailmix_creator_id=lfrascarelli&trailmix_slug=service-cloud-consultant-certification

Data Categories:

Knowledge in Console comparison for Classic and Lightning:

Lightning Web Components Pub-Sub:

Search from a developer perspective:



About Steve

Steve MunLeeuw is a Technical Architect at Statera.