A bad article stops being a content problem
A knowledge base written for people carries a subsidy nobody records. A support rep who opens an article written for the wrong product version spots the version line, sighs and applies judgement. They fill in the step somebody forgot to write down. They notice the screenshot is three releases old and keep going anyway.
A retrieval step has none of that. It returns the passages that match the query, and the model answers from them with the same steady confidence whether the article was accurate, obsolete or written for a market this customer does not live in. Knowledge quality becomes answer accuracy, and answer accuracy carries a blast radius the size of your contact volume.
The work that fixes this sits in Service Cloud configuration more than in writing style. Record types, data categories, channel visibility, versioning and archival decide what retrieval can find and what it can rule out. Editing prose will not rescue an answer that came from an article the retrieval step should never have reached.
Record types decide what retrieval can tell apart
Most orgs run one knowledge record type covering everything. It has a title, a rich text body, maybe a resolution field, and every author pours whatever they have into it. People cope with that, because two lines of reading tells a rep whether they are looking at a rule or a set of steps.
Retrieval has no such tell. A refund policy and a refund procedure look alike at the passage level, and a model asked whether a customer qualifies for a refund will answer from either. One states an entitlement rule. The other lists the clicks. Answer the entitlement question from the procedure and you get a confident wrong answer that nobody reviewing the transcript will spot as wrong.
Separate record types give retrieval and the agent topic something to filter on. A policy type, a procedure type, a troubleshooting type and a product fact type each carry their own fields, and each can be scoped to the questions it should answer. The same instinct shows up in deliberate case object design, where one object holding every kind of work makes every report harder.
Category visibility is now a disclosure control
Data categories exist so reps and customers see different slices of one library. The internal troubleshooting note stays in the console. The customer-facing version goes to the help site. Channel visibility on each article settles which audiences can reach it, and most orgs set that once during implementation and never look again.
Point a customer-facing agent at the same library and the cost of a mistake changes shape. An internal-only article that reaches an external conversation gets paraphrased into the reply. Escalation thresholds, margin guidance, the workaround for a defect you have not announced yet. That becomes a disclosure incident, and the customer finds it before your review process does.
Category assignment and channel visibility now deserve the scrutiny you give a permission set. Every agent that retrieves knowledge should carry an explicit category filter, and somebody should be able to prove which articles a given agent can reach. That proof belongs in the same evidence pack as your permission audit, and it should be repeated whenever a new topic goes live.
What an agent sees while an article is being revised
Salesforce Knowledge keeps one published version and as many drafts as you want. A human editor working in a draft knows the published version is still live, because both sit in front of them. A retrieval configuration sees whatever it was pointed at, and almost all of them are pointed at published articles only.
That default is right most of the time and occasionally expensive. An article found to be wrong on Tuesday morning stays published while somebody rewrites it, so the agent keeps answering from the known-bad version for as long as the rewrite takes. Unpublishing is faster than fixing, and a failed retrieval hands the contact to a person.
Settle that rule before you need it and write it into the knowledge process. Anyone who finds a factually wrong article should have standing authority to unpublish without an approval cycle. Missing knowledge produces a handoff and a slightly longer wait. Wrong knowledge produces an answer that lands in a transcript and gets quoted back at you.
Split by the answerable question
Granularity moves retrieval accuracy more than any other content decision. A long article that answers six related questions retrieves poorly for all six, because the passage matching the query sits beside five passages that do not, and the model has to work out which part of the article the customer meant.
Splitting by topic feels tidy and helps very little. Splitting by the question a customer actually asks helps a lot. One article per answerable question, phrased close to the words a customer would use, gives retrieval a clean target and gives you something testable. Ask the question, look at what came back, see whether the right article ranked first.
Titles and summaries stopped being decoration the day something started retrieving them. A title reading Returns tells a retrieval step almost nothing. A title reading How a customer returns an item bought in a store contains the words a real query will contain, and the summary field underneath is often the only text the model reads before deciding the article is relevant.
Say what the article does not cover
Explicit scope belongs in the article text rather than in the author's head. An article stating which product version, which region and which customer tier it applies to gives retrieval something to exclude on when the case does not match. An article leaving scope implicit cannot be excluded at all.
That distinction decides whether a filter can do its job. Two articles about returns, one for a market with a fourteen day window and one for a market with thirty, are indistinguishable to a retrieval step unless each says which market it covers. The model will pick one of them and sound certain about it.
The encouraging part is that every one of these moves helps the human reader too. Shorter articles, honest titles, stated scope and a plain statement of what the article leaves out. Support teams have asked for that for years without a business case big enough to fund the rewrite. Answer accuracy supplies one, and the preparation described in a practical agent readiness check usually surfaces the worst offenders first.
A stale article costs more than a missing one
Archival matters far more once something retrieves automatically. A human reading a three year old article about a retired product notices the product name and moves on. A retrieval step has no such reflex, and a superseded article that still ranks well will keep producing answers about something you no longer sell.
Give every article a named owner and a review date somebody is measured against. Ownership by team fails, because teams do not open reminders. Ownership by person holds up when the review list turns up in a queue that person already reads. Set the review interval by volatility rather than by calendar habit, so pricing and policy articles come round more often than an installation procedure nobody has touched in two years.
Then measure what retrieval actually does. Track which articles get retrieved and which of those conversations resolve without a handoff. An article retrieved often and resolving rarely is the strongest signal you will get that something inside it is wrong, ambiguous or out of scope for the question it keeps attracting. Read that pair of numbers alongside what Agentforce actually does with a retrieved article.
Here is a check worth running this week. Take the twenty questions your service desk answers most often, put each one through the agent, and record three things: the article that came back, whether it was in scope for that question, and whether its scope was stated anywhere in the text. Everything failing the third column is your rewrite list, and it will be shorter than you fear.
