Most Knowledge bases I inherit are not broken because the content is bad. They are broken because nobody decided who writes, who approves, who publishes, and who retires an article, so all four jobs collapse into whichever agent happened to be free that afternoon. The result is a tab full of half-finished drafts, three near-identical articles on the same modem reset, and a search box that returns everything except the thing the agent needed during a live call.
I ran into a clean version of this at a telco support org. Tier 1 agents had a perfectly good article on resetting a customer's modem remotely, but it was buried under a dozen marketing pieces about new data plans, and the one technical article that mattered had a title so generic ("Internet help") that the search engine had nothing to grab onto. The fix had almost nothing to do with writing skill. It was authoring discipline, a real approval path, a sane archive policy, and about an hour of search configuration.
That is the frame I want to use here. Knowledge in Service Cloud is four connected disciplines, and a consultant earns their fee by getting the client to make explicit decisions about each one before a single article goes live.
Authoring: structure is a search feature, not a style preference
The single most useful thing you can hand a content team is a template per record type. A troubleshooting article and an FAQ are not the same shape, and forcing them into one layout produces mush. For troubleshooting content I push a consistent skeleton: a keyword-rich title, a one-to-two sentence summary that shows in the search preview, then symptom, cause, resolution steps, verification, related articles, and metadata like applicable products and a last-reviewed date. An FAQ only needs question and answer. A policy article only needs the policy body and an effective date. The record type drives the page layout, and the page layout enforces the structure.
Salesforce does not ship a template engine for Knowledge, which surprises clients every time. There is no native "start from boilerplate" button. The workaround that actually moved the needle at the telco was a small custom Lightning component that let an author pick a scenario (slow internet, no TV signal, mobile activation) and pre-filled the rich text areas with a skeleton. That cut authoring time from around thirty minutes to under ten per article. The trap with any boilerplate is the author who leaves the placeholders in, so I pair it with a validation rule that blocks save if the body still contains strings like [describe] or [TODO].
Title and summary deserve real attention because they carry the most weight in search. A good title leads with the customer's problem in the customer's words, not the solution and not generic filler. At a bank I worked with, the article on ATM disputes was titled "ATM withdrawal failed but account debited" precisely because that is how customers describe it, not "Cash dispenser reconciliation procedure." If your callers say "lag," the title needs the word "lag" in it, however imprecise that feels to the engineer who wrote the content.
On the rich text body itself, the rules are unglamorous but they hold up. Use headings and numbered steps so agents can skim under pressure, link related articles through the Knowledge lookup field rather than pasting raw URLs that rot, and keep images on Files with sharing that actually works. Avoid pasting straight from Word, which drags in styling that breaks on mobile, and skip embedded video, which the rich text area does not support.
Approval: the process that does not publish
The most common misunderstanding I correct on Knowledge approvals is that approving an article does not make it live. Publication status (Draft, Online, Archived) is managed by the system through publish and archive actions, not by setting a field, and an approval process leaves the article sitting in Draft until somebody explicitly clicks Publish. Salesforce deliberately separates the approval decision from the publishing action, and clients who assume otherwise ship articles that everyone "approved" and nobody published.
You build the approval process on the Knowledge object the same way you would on any other. At a hospital client, peer review was a hard requirement: a clinical article needed sign-off from a subject-matter specialist and from clinical quality before it could go out. We modeled that with a custom validation status picklist plus two lookup fields for the reviewers, then an approval process with entry criteria on validation status and record type, a first step routing to the named specialist, a second step routing to quality, and a final action that emailed the Knowledge admin "ready to publish" with a link. The admin, not the approval process, did the publishing.
Two pitfalls show up here repeatedly. First, lock the record on the initial submitter action and restrict approvers to approve or reject only, because by default an approver with edit rights can quietly change the body, and then the second reviewer approves something the first reviewer never saw. A read-only permission set for approvers closes that gap. Second, plan for the approver who goes on leave with an article locked behind them. Enable delegated approval and make sure an admin can recall or reassign, or your draft queue stalls for two weeks.
If a client genuinely wants auto-publish on final approval, it is possible but not native. The approval process has no built-in publish action, so you wire the final approval to an Apex call into KbManagement.PublishingService or flip a field that a record-triggered flow watches. I push back on auto-publish for anything compliance-sensitive, because it removes the last human checkpoint before content goes live.
Lifecycle: archive over delete, and respect the version model
Archive and delete are not interchangeable, and the difference matters more than clients expect. Archiving moves an article from Online to Archived: it disappears from public and customer search, internal users with the right permission can still see it, and crucially the references from old cases survive. Delete sends the whole thing to the Recycle Bin for fifteen days and then it is gone forever, references included. My default is archive in nearly every case. Reserve delete for genuinely wrong content, test data, or duplicates.
The version model trips people up because there are three independent axes at play. There is the master version number that increments as content evolves, there is the language version where each translation is a separate record, and there is the publication status that each of those versions carries independently. When an editor clicks "Edit as Draft" on a live article, Salesforce clones it into a new draft at the next version number while the current version stays live for users. Publishing as a new version then promotes the draft to Online and archives the previous version automatically, assuming the default Knowledge setting is left on.
Translation is where the version model bites. When the master article moves to v2, the existing translations stay Online showing the old content, because Salesforce does not auto-retranslate. At the hospital, the Vietnamese master got updated to reflect a new screening step, and the English version kept showing the previous procedure to expat patients. The mitigations are a flag that marks translations outdated when the master republishes, a banner on the portal warning that the translation may lag, and ideally a flow that auto-submits the language versions for retranslation the moment the master goes live.
One more lifecycle gotcha that generates support tickets: archiving an article does not clean up the case links pointing at it. An agent opening an old case clicks the article link and hits a dead end. The process fix is to pair every archive with a step that finds related cases and notes the replacement article number, or a flow that repoints the reference.
Search: relevance is mostly configuration
Once content and lifecycle are sound, search is where agents either trust the Knowledge base or stop using it. Salesforce ranks results on field weight (title outranks summary outranks body), term frequency, recency, popularity, and Data Category match against the case context. You cannot see the exact formula and you do not need to. What you can control is the inputs.
Three levers do most of the work. Synonym groups bridge the gap between how customers talk and how authors write, so a group like "internet, wifi, network, broadband" means a search for "wifi slow" also matches articles written around "internet slow." Promoted search terms pin a specific article to the top for a given keyword, which is invaluable for an urgent fix or a seasonal article that the algorithm would otherwise rank low. And Data Category visibility on the agent's profile has to actually match the categories on the articles, or the most common "why can't I see anything" ticket turns out to be a permissions mismatch, not a missing article.
In the Service Console, suggested articles take this further by querying off the case subject and description automatically and surfacing the top few in the Knowledge sidebar, where the agent inserts the body straight into the case feed or the customer email. At the telco we configured the sidebar to filter on the case's service type via Data Category, promoted the modem reset article for the relevant keywords, and the article that used to be invisible was suddenly the first thing an agent saw.
Watch the abuse cases. Marketing will ask you to promote twenty plan-promotion articles under "data plan," which buries the troubleshooting content agents actually need, so keep promoted terms to genuinely critical articles and review them monthly. Synonym groups that share a term create accidental bridges, so audit them rather than letting "network" quietly link unrelated contexts. And set expectations on the search index, which can take fifteen to thirty minutes to pick up a freshly published article, because the "I published it, why can't I find it" complaint is otherwise inevitable.
The principle that ties all four disciplines together is that a Knowledge base is an operational system, not a content folder. Decide explicitly who authors, who approves, who publishes, and who retires; make those decisions visible in the configuration; and the search box stops being the part everyone complains about.
Implementing or optimizing Service Cloud? Our Salesforce team runs discovery, designs the case process, and configures Service Cloud, Omni-Channel, and Knowledge on production engagements. Get in touch ->
See our full platform services for the stack we cover.
