Article
An Article in Salesforce is a Knowledge Article, the platform's unit of structured help content.
Definition
An Article in Salesforce is a Knowledge Article, the platform's unit of structured help content. Each article carries a Title, a URL Name, a rich-text Body, data category assignments, channel assignments, and version metadata. Authors write articles, reviewers approve them, and the org publishes them so agents, customers, and partners can find the answer they need. In Lightning Knowledge, every article lives on the standard Knowledge object rather than the per-type objects used by Classic Knowledge.
Articles are how an organization captures institutional knowledge in a form the platform can serve. An agent reading a case pulls the relevant article from the Knowledge sidebar. A customer searching a Help Center finds the same article ranked by relevance. Einstein and Agentforce ground their answers in published articles so the response cites a real source. The article's lifecycle (Draft, Online, Archived) decides which version each audience sees.
How an Article behaves across its lifecycle, channels, and surfaces
Article types and the Lightning Knowledge data model
Classic Knowledge gave every article type its own object, so FAQ, How-To, and Process articles were separate sObjects. Lightning Knowledge replaced that design. Now every article lives on the standard Knowledge object, and record types take the place of the old article types. An admin creates record types like FAQ, Procedure, and Release Note, gives each its own page layout, and they all share one object. Under the hood the platform exposes two related records. KnowledgeArticle is the parent that represents the article across all of its versions, and KnowledgeArticleVersion represents one specific version. Their API names default to the Knowledge__ka and Knowledge__kav suffixes, which you see whenever you query Knowledge in SOQL or build an Apex integration. Migration from Classic to Lightning Knowledge is a one-time project, and most large orgs finished it years ago. The practical effect for an author is simple. You pick a record type when you create the article, and that choice drives the layout and the fields you fill in, not which table the record lands on.
Drafting, review, and version history
An author starts by creating a Draft. They write the content in a rich-text editor, assign data categories, set channel visibility, then either submit for review or publish directly if they hold the right permission. Every published article keeps its full version history, so you can see who changed what and roll back if a revision goes wrong. The version model is the part people miss most often. When you edit a published article, Salesforce creates a new Draft version and leaves the live Online version untouched. The customer keeps seeing the old text until the new Draft is itself published. That separation lets an editor rewrite a procedure over several days without ever exposing a half-finished article to the public. Translations follow the same pattern, each language version has its own draft and publish state. Behind the buttons sits the KbManagement.PublishingService Apex class, which publishes, archives, edits, and deletes articles programmatically. Teams that bulk-load content or sync from an external system call that class instead of clicking through the UI one record at a time.
Data Categories and channel visibility
Two settings decide who can see an article, and authors edit them on almost every record. Data categories are the hierarchical taxonomy that classifies articles, grouped into category groups like Products or Sales Regions. They do double duty. They organize the knowledge base for browsing and search, and through category group visibility they control which users and customers can read which articles. Channels are the second lever. The four channels are Internal App, Customer, Partner, and Public Knowledge Base. Internal App means employees in the org. Customer and Partner expose the article to those community audiences through Experience Cloud. Public Knowledge Base makes it visible to anyone, no login required. An article shared only to Internal App never appears on the Help Center, no matter how good the content is. Getting category and channel right is most of the curation work in a Knowledge program, and the channel checkbox is the single most common reason an article that looks published still cannot be found by the people it was written for.
Articles attached to Cases
Agents connect articles to cases through the Case related list and the Knowledge component. Attaching an article records which one helped resolve the case. That link feeds reporting, so a manager can see resolved-by-article rates and find which articles do the heavy lifting. It also trains Einstein, which learns which articles tend to resolve which kinds of cases and uses that signal to recommend articles and reply text on future cases. When configured, an attached article can be sent to the customer by email or surfaced on the case feed, turning a single piece of content into both an agent aid and a customer-facing answer. This loop is the core of Knowledge-Centered Service, the methodology where solving a case and capturing the answer are the same act. Every case worked is a chance to create or improve an article, and every article attached makes the next similar case faster to close. Orgs that measure article reuse usually find a small set of articles carries a large share of deflection.
Articles in the Service Console and Knowledge sidebar
The Service Console surfaces Knowledge through the Knowledge component, often docked as a sidebar next to the open case. The component searches articles using the case subject and description, so the agent sees likely answers without typing a separate query. From there the agent can open an article inline, attach it to the case, or insert it into an email to the customer. This is the most-used Knowledge surface for human agents, because it puts the answer one click from the work they are already doing. Search relevance matters here more than anywhere else. The component ranks by the words in the case, which is why article titles and summaries carry so much weight. A precise title that matches how customers describe the problem floats to the top of the sidebar, while a vague title buries a perfectly good article three results down where no busy agent will scroll. Admins tune which fields are searchable and how data categories filter results to keep the sidebar fast and accurate.
Articles in Experience Cloud Help Centers and self-service
The same article that helps an agent through the sidebar can help a customer through self-service. Experience Cloud sites expose articles with the Knowledge component, a searchable index, and category-based navigation. Customers reach articles three ways. They search, they browse by data category, or they follow a deep link from an automated email or a case communication. Channel visibility decides what each visitor sees. A logged-in customer sees Customer-channel articles, a partner sees Partner-channel articles, and an anonymous visitor on a Public Knowledge Base sees only the public set. This is where good deflection happens. A customer who finds the answer themselves never files a case, which lowers volume and frees agents for the harder problems. Building the site well means mapping data categories to a navigation a non-expert can follow, writing titles in the customer's words rather than internal jargon, and confirming after every publish that the article actually appears for the intended audience. The publish button is not the finish line, visibility verification is.
Einstein, Agentforce, and reporting on content health
AI sits on top of articles as a discovery and synthesis layer, and the article stays the authoritative source. Einstein for Service reads case content and recommends articles to attach or reply text to send. Agentforce goes further, grounding its generative answers in published articles so the bot cites a real, approved source instead of inventing one. The quality of these AI features rises and falls with the quality of the articles underneath them, which is why content health is a discipline, not an afterthought. Standard report types cover article views, votes, search-with-no-results, and article-to-case attachment counts. Mature programs build a dashboard that tracks publishing rate, average article age, top-viewed articles, archive count, and search miss rate. The search-no-results report is the most valuable of these, because it lists exactly what customers looked for and could not find, which is the highest-priority backlog for new content. A knowledge base without metrics decays quietly, articles go stale, links rot, and trust erodes long before anyone notices.
How to create and publish a Knowledge Article
Authors create a Knowledge article from the Knowledge app or the Article Manager. The flow below covers a single new article from blank draft to a published version visible in the right channels. You need the Knowledge User feature license and create permission on the relevant record type.
- Open Article Manager and click New
From the App Launcher, open the Knowledge app and go to Article Manager. Click New, then pick the record type (for example FAQ or Procedure). The record type sets the page layout and the body fields you will fill in.
- Write the Title, URL Name, and Body
Give the article a clear, search-friendly Title that matches how customers phrase the problem. Set a stable URL Name, since it appears in permalinks. Write the rich-text Body and any summary field the layout includes.
- Assign Data Categories and channels
Tag the article to the right data categories so it appears in the correct browse paths and respects category group visibility. Set the channels (Internal App, Customer, Partner, Public Knowledge Base) for every audience that should see it.
- Submit for review or publish
Save the draft, then either submit it into your approval process or publish it directly if you have permission. Publishing moves the version to Online. Editing later creates a new draft and leaves the live version up until you publish the change.
The headline shown in search results and the sidebar. It is the single biggest driver of whether the article gets found, so write it in the reader's words.
The unique, URL-safe identifier used in the article's permalink. Keep it stable, since renaming it breaks every inbound link from cases, emails, and external sites.
Chosen at creation, it determines the page layout and the body fields available. It replaces the old Classic article types.
The rich-text content of the answer. Layouts can define more than one body field, so fill the ones your record type exposes.
- Channel visibility is the most-missed setting. An article published only to Internal App will never appear on the customer Help Center.
- Editing a published article creates a new draft, it does not change the live version until you publish again. Do not assume the customer sees your edit immediately.
- Data category group visibility can hide an article from a user even when the channel is correct, check both when troubleshooting access.
- Authoring needs the Knowledge User feature license. A profile permission alone is not enough.
Prefer this walkthrough as its own page? How to Article in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Article.
Hands-on resources to go deeper on Article.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is an Article in Salesforce Knowledge?
Q2. What are the main states an Article passes through in its publishing lifecycle?
Q3. How does Lightning Knowledge model the different kinds of Articles such as FAQ and Procedure?
Discussion
Loading discussion…