Setting up Salesforce Knowledge comes down to five decisions made in order: which record types your articles need, how data categories will classify them, which audiences see each article, who writes, reviews and publishes, and how articles stay accurate once they are live. Search tuning and AI grounding come after that, because both rely on the structure underneath. Orgs new to Knowledge start on Lightning Knowledge, which cannot be switched off once enabled, so test the design in a sandbox first.
Record types: one per kind of article
In Lightning Knowledge, every article lives on a single Knowledge object, and record types take the place of the article types used in Classic. A record type controls which fields an article has and how it is laid out, so it should reflect a genuinely different shape of content: a short FAQ answer, a step-by-step procedure, a troubleshooting article with symptoms and cause, or a policy statement. If two proposed types would have the same fields, they are one type with a category difference.
Keep the field list short. A title, a URL name, a summary written to stand alone, and one or two rich text bodies cover most needs. Add an internal-notes field for agent-only guidance that should never reach a customer, plus the four visibility checkboxes Salesforce provides for the internal app, customers, partners and the public knowledge base. The guided setup flow creates a default FAQ record type and layout, which is a reasonable place to start and extend.
Plan for volume too. Every article can carry one draft, one published version and several archived versions, each of which may be translated, and edition limits apply to articles, versions per article and languages. A multilingual knowledge base with a busy editing cycle reaches those limits far sooner than the article count suggests.
Data categories and who can see what
Data categories classify articles so people can filter and browse them. You build category groups, such as Products or Regions, each holding a hierarchy up to five levels deep and up to 100 categories. By default only three groups can be active at once, so choose dimensions that matter across the whole knowledge base. Keep a new group inactive until its hierarchy and visibility settings are finished, because activating it exposes it to users.
The bigger decision is how access is controlled. Under the original model, data category visibility, set by role, permission set or profile, decides which categorized articles a person can see. Since Summer '20 you can instead turn on standard Salesforce sharing for Knowledge, using org-wide defaults, ownership and sharing rules on article versions; categories then only classify and filter. Standard sharing suits orgs that need rules based on record type, language or custom fields. Category visibility suits simpler setups where a product or region hierarchy already maps to who should see what. Decide before you load content, since switching later means rebuilding access.
Map case fields to categories as well. With data category mapping, a case's product or type field can push matching articles to the top of the suggested list, which saves agents a search on every case.
Audiences: internal, portal and public
| Channel | Who reads it | What to set up | Watch for |
|---|---|---|---|
| Internal App | Service agents and other Salesforce users | Knowledge component on the case page, record type layouts, agent-only fields | Internal notes and workarounds that later get marked for external channels by mistake |
| Customer | Logged-in customers in an Experience Cloud site | Site search and article pages, guest and member access, category visibility or sharing for site users | Articles that reference internal systems or staff-only steps |
| Partner | Resellers, agents or dealers in a partner site | Partner-specific categories or sharing rules, partner user access | Pricing, margin or program details reaching the wrong partner tier |
| Public Knowledge Base | Anyone, without logging in | A public Experience Cloud site with guest access to published articles | Content that should require a login; public visitors cannot rate articles, so collect feedback another way |
Channels are set per article, so the author's choice of checkboxes decides exposure. Make that choice part of the review rather than leaving it to habit. A good default is internal only, with external channels added deliberately when a reviewer confirms the article is written for customers.
The authoring workflow and approvals
Articles move from draft to published to archived. Editing a published article creates a new draft version while the current one stays live, so customers never see a half-finished edit. Salesforce lets you add approval processes per record type, which is how you require legal or product sign-off on a policy article without slowing down every FAQ. A Validation Status field, with values such as Validated, Not Validated or Needs Review, records whether content has been checked.
- Grant authoring to a defined group, and give most agents read access plus the ability to flag or suggest changes.
- Draft new articles from real cases, in the words customers used, and link the article to the case that prompted it.
- Route external or policy content through an approval process on its record type; let internal FAQs publish after a peer check.
- Set Validation Status on publish, and require a reviewer to confirm the channel checkboxes before anything goes external.
- Assign each article an owner and a next review date in custom fields, since Salesforce does not schedule archiving on its own.
- Archive rather than delete, and use a scheduled Flow to flag or archive articles whose review date has passed.
Two cautions from the documentation are worth passing to authors. Several people can edit the same article at once and overwrite each other without warning, so assign articles rather than letting anyone edit anything. Article records locked in an approval process cannot be unlocked, so reviewers need to approve or reject promptly.
Search, and grounding AI agents
Agents and customers judge Knowledge by whether search finds the right article on the first try. Write titles as the question or symptom a person would type, add synonym groups for product nicknames and abbreviations, and review searches that returned nothing each month; those gaps are your next articles. Article reports show views, votes and case attachment counts, which reveal articles nobody opens and articles that keep resolving cases.
The same articles can ground Agentforce. An Agentforce Data Library built on Knowledge indexes your articles and sets up a search index and retriever, and the standard Answer Questions with Knowledge action pulls relevant passages into the prompt before the agent replies. That means the agent's answers are exactly as current and correct as the articles, and an internal-only workaround indexed by mistake can end up in front of a customer. Decide which record types and channels an agent may draw on, and test with questions taken from real cases before going live.
Keeping articles current
Tie Knowledge upkeep to the events that make articles wrong: product releases, policy changes and spikes in a case type. Add an article check to the release checklist, so whoever ships a change names the articles it affects. When a new question shows up in several cases in a week, write the article then, while agents still remember the answers they gave. Keeping the knowledge base current is also what keeps self-service and any AI agent trustworthy, which is the reason to build it well in the first place.
