What Salesforce Knowledge management does well, and where it stops

The short version

• Salesforce Knowledge manages articles somebody wrote into Salesforce, not the documents your team already keeps elsewhere.
• The tool is not the bottleneck. Versioning, approvals and search all work; the articles are what goes missing.
• Availability depends on your Salesforce edition, so it is a licensing question before it is a configuration question.
• An AI layer on top is priced per action, which gives every answer a unit cost whether it is right or wrong.
• Answers that span contracts, tickets and wiki pages are a retrieval problem, not a Salesforce configuration problem.

What does Salesforce Knowledge actually do?

It manages the lifecycle of articles and puts them in front of agents and customers. An article has versions, a draft state, a published state and an archive. You can route it through an approval process, tag it with data categories, attach it to a case, and publish a selected subset to a public help centre. That is the shape of the whole feature, and it is a decent shape.

The case link is the part worth having. An agent working a case sees candidate articles in the console, attaches the one that resolved the issue, and that attachment becomes data. Over a few months you can see which answers close which cases, which is more useful than a page view count, because it tells you what the article did rather than how many people landed on it.

Whether you have it at all is a licensing question first. Salesforce lists Knowledge Management as a Service feature in the edition comparison on its own small business pricing page, so the answer depends on edition and licence rather than on configuration. Check your contract and the current pricing page before you design anything, because the design changes if the feature sits one edition above you.

Where does Salesforce Knowledge stop?

At the edge of Salesforce. Knowledge manages articles that somebody deliberately wrote into Salesforce. It has no view of the contract in Google Drive, the runbook in Confluence, the pricing exception agreed in a Slack thread in March, or the PDF a supplier emailed to one person. Those are the documents people go looking for when a case gets difficult.

This matters because real questions are rarely answerable from one system. 'Can this customer get a refund after 40 days' sits partly in a published policy article and partly in the signed order form. Knowledge answers the published half cleanly and is blind to the specific half. The agent still ends up in a drive folder, and the time saved by good articles gets spent there instead.

Salesforce Files looks like a way around this and is mostly a trap. You can attach documents to records and search their contents, but a file on an opportunity is not an article: no review cycle, no versioned publication, no categories, no owner. It is storage with search over it. Depending on it means your answer depends on whether somebody uploaded the right version of the right file.

Who writes the articles, and what happens when nobody does?

The service team writes them, usually at case closure, and when nobody does you have an empty cabinet with an excellent filing policy. This is the normal failure of Salesforce Knowledge and it is not a Salesforce failure. Versioning works. Approvals work. Search works. The articles are missing, because writing them is the one part of the system that cannot be configured.

The fix is unglamorous. Name an owner per article type, make 'write or update the article' part of closing a repeat case, and put a review date on anything that states a price, a policy or a deadline. Then archive without sentiment. An article nobody has opened in a year is either badly titled or no longer true, and both deserve a decision rather than a place in the index.

It is also fine to decide the apparatus is not worth it. With three agents and forty recurring questions you do not need data categories, a translation workflow or an approval chain. Those exist for organisations with hundreds of articles and regulated wording. A flat set of forty well-titled articles that are actually true beats a taxonomy nobody maintains, every time.

A sane first thirty days

1. Pull the top thirty case reasons from the last quarter and write one article for each, in the words customers use.
2. Give every article an owner and a review date before you publish it.
3. Turn on the Knowledge component in the case console so agents attach articles while they work.
4. Publish only the subset a customer should see, then check the public channel afterwards.
5. Log the searches that return nothing, and read the list weekly.
6. Leave the wiki, the drive and the code repository where they are until you have evidence that moving them helps someone.

Should the knowledge base live in Salesforce or outside it?

In Salesforce when the audience is service agents and customers and the content is answer-shaped. Outside Salesforce when the audience is the whole company and the content already lives in a drive, a wiki, a ticket queue and a code repository. Most organisations need both, which is not a contradiction and does not need resolving.

The expensive mistake is migration. A team decides Salesforce will be the one place everything lives and starts converting wiki pages into articles. Six weeks later half the content exists twice, neither copy is authoritative, and engineering is still editing the version that is not in Salesforce. Content follows the people who maintain it. Move it away from them and it rots faster than it did before.

The alternative is to leave each document where it is maintained and put one retrieval layer across the sources, resolving each user's permissions at query time rather than copying access rules into an index. Salesforce Knowledge stays the published, customer-facing surface. The retrieval layer covers the internal half of the question. The hard part is the permissions, not the search.

Which problem are you solving?

How much does an AI layer on top of this cost?

Per action, which is the number to model. Salesforce prices Agentforce in Flex Credits, at 20 credits per agent action, with credits sold at $500 per 100,000. That is ten cents an action at list price, and one customer conversation is usually several actions. Multiply actions per conversation by conversations per month and you have a monthly figure before any discount.

The cost that hurts is not the credit, it is the wrong answer. An agent grounded on forty stale articles will produce confident wrong answers at ten cents each, and each one generates a second contact and a worse mood. Grounding quality is the ceiling on what any agent layer can be. Deploy it over a knowledge base you would be content to see quoted back to you in public.

If you want to compare against staff cost, use published wage data rather than a saving claimed in a vendor deck. The US Bureau of Labor Statistics publishes national wage estimates for customer service representatives, and for software developers if you are also costing the build side. Look up the current figure for your own market, do the arithmetic in the open, and let people argue with it.

Can you use the vendor's research as your business case?

No, but you can use its methodology. Salesforce publishes survey research with its samples and fielding windows stated, which is more than most vendors manage. Its sixth State of Service report surveyed over 5,500 service professionals across 30 countries, with fieldwork running from 8 December 2023 to 22 January 2024. Read those dates before quoting anything from it in a 2026 budget conversation.

The same applies to the rest of the set. The small and medium business trends report drew 3,350 responses from leaders of businesses with 200 employees and under, fielded between 3 August and 16 September 2024, and a separate consumer survey covered 15,015 adults across 18 markets through YouGov in mid 2024. These describe what samples reported at a point in time. None of them predicts your deflection rate, which depends on your articles.

How do you know whether any of this is working?

Four numbers, none of them a headline. Searches that returned nothing. Cases closed with an article attached. Articles with no views in ninety days. Repeat contacts on the same question within a week. Read together they tell you whether the knowledge base answers questions, which is the only thing it was bought to do.

Zero-result searches are the best free backlog in the system, because they are written in customer language and they name the gap exactly. Repeat contacts catch what an AI layer hides: an agent can answer quickly, confidently and wrongly, and the first three numbers will look fine while the fourth climbs. If you only watch one, watch that one.