Article Review
An Article Review is the controlled step where a Salesforce Knowledge article moves from a finished draft into reviewer evaluation before it goes live.
Definition
An Article Review is the controlled step where a Salesforce Knowledge article moves from a finished draft into reviewer evaluation before it goes live. A subject matter expert, editor, or compliance owner reads the draft, checks accuracy and tone, confirms the Data Category and channel choices, then approves it for publication or sends it back to the author with comments. Salesforce supports this step through standard Approval Processes (or a Flow-built approval) layered on the Knowledge object, plus optional automation that runs checks before a human ever opens the draft.
The review step matters because a Knowledge article becomes operational truth the moment it publishes. A wrong instruction in a how-to article costs an agent time on every case that surfaces it. A misleading answer shows to thousands of customers per quarter through self-service. Review is the gate that keeps weak content off the customer-facing surface. One detail trips up many teams: even after an approval completes, Salesforce does not auto-publish. A person still clicks Publish.
How the review gate fits the Knowledge lifecycle
Where review sits in the article lifecycle
Every Salesforce Knowledge article can hold one draft version, one published (online) version, and several archived versions, and each version can have its own translations. The author works in the draft. When the draft is content-complete, it enters the review window before it can become the published version. Review is not a separate object or a hard status of its own. It is the period during which the draft is submitted for approval and a reviewer decides its fate. If the org runs an Approval Process on Knowledge, the draft shows a Submit for Approval action, and submitting locks the record so the author cannot keep editing while a reviewer reads it. The reviewer either approves, which clears the path to publish, or rejects, which returns the draft to the author. The key thing to internalise is that approval and publication are two different events. Approval ends the review. Publication is a deliberate second action that swaps the approved draft in as the live version. Teams that assume approval equals "now live" are surprised when nothing reaches customers until someone clicks Publish.
Approval Process integration on Knowledge
The standard Approval Process feature can be configured directly on the Knowledge object so that drafts route to the right reviewers. Each approval step assigns approvers, sets entry criteria for which articles need which reviewers, and can fire actions on approval or rejection. Salesforce gives one important piece of guidance here: articles are not published automatically at the end of an approval process, and support reps must click Publish. To make that work cleanly, the recommended final approval action leaves the record editable rather than locked, which keeps the approved draft in a state where a publisher can act on it. There is also a useful access nuance. A user who has only read access to the article can publish a draft once an approval process is associated with the article and that approval is complete but the article is not yet published. When an Approval Process is enabled on the article, the Approval History related list appears on the record so anyone can audit who approved what and when.
Flow-built approvals, the modern path
Salesforce now lets you build approval logic for Lightning Knowledge with Flow. A Flow-based approval can route a submitted draft to approvers, branch on field values or Data Category, and call follow-up actions, which gives more control than the older point-and-click approval steps alone. Spring '25 (API version 254) introduced advanced approval processes for Knowledge articles, expanding what reviewers and admins can express in the routing and decision logic. The practical reason to reach for Flow is conditional review. You rarely want every article to face the same reviewer. A pricing change should reach finance. A security-sensitive procedure should reach the security team. A typo fix from a senior author may need no second set of eyes at all. Flow approvals let you encode those rules so the right human sees the right draft, and only the right draft. Whichever engine you pick, the publication rule does not change. The Flow ends the review by approving; a person or an explicit publish action still makes the article live.
What a reviewer actually checks
A repeatable review depends on a written checklist, not on each reviewer's private bar. Effective reviewers confirm a short, consistent set of things. They check factual accuracy against the product or policy as it exists today. They check tone and voice against the brand style guide so a hundred articles read like one author. They confirm the Data Category and channel assignments, because a correct article filed under the wrong category is invisible to the people who need it and visible to people who should not see it. They scan for sensitive content that must not reach customers, verify that links resolve, and look for overlap with an existing article that already answers the question. The reviewer also weighs whether the article belongs in the knowledge base at all, or whether it is a one-off that should live in a case comment. Write this checklist before you configure any approval mechanics. The Approval Process is the plumbing; the checklist is the actual review, and it is the part that protects content quality.
Rejection, comments, and the revision loop
When a reviewer rejects a draft, it returns to the author, usually with comments that explain what to fix. The author revises and resubmits, and the cycle repeats until the draft is approved. Approval comments captured during this loop become a small audit trail of the decision, which is useful months later when someone asks why an article reads the way it does. Healthy programs cap the loop at two or three rounds. Past that point, the back-and-forth in comments is a poor substitute for a short conversation, and dragging a draft through a fourth and fifth rejection wastes both the author's and the reviewer's time. A persistent pattern of rejections is itself a signal worth reading. If one author keeps getting rejected, the fix is author training, not more review rounds. If one reviewer rejects far more than peers, the fix may be calibration so the team shares a common standard. Treat the rejection rate as a metric, not as noise.
Service-level targets and reviewer load
A review program lives or dies on speed. Drafts that sit in a Pending Review queue for two weeks are a broken program; a few days from submit to approve is the right target. Build a dashboard on the Approval History and process data that measures submit-to-approve latency, the number of drafts waiting per reviewer, and the rejection rate, then watch for queues that back up. A reviewer with a persistent backlog needs one of two things: more review capacity, or a stricter author quality gate so fewer weak drafts ever reach them. Both are valid; the data tells you which. It also helps to separate the bottleneck cleanly. If approvals are fast but few articles publish, the constraint is upstream in authoring or downstream at the publish step, not in review. If drafts pile up unapproved, review is the constraint. Pairing review metrics with content metrics like publish rate and archive rate keeps the team honest about where the real friction lives rather than guessing.
Automating the cheap checks first
Not every review judgement needs a person. Lint-style automation catches the obvious problems before a human spends attention on them: an empty body, a missing Data Category, a broken link, a forbidden word, a draft submitted with no summary. A Flow can run these pre-checks when an author submits and block the draft from advancing if it fails, which means reviewers only ever see drafts that already clear the mechanical bar. That frees human review for the judgement calls automation cannot make, like whether the explanation is actually clear or whether the article duplicates one that already exists. The split is the whole point. Machines should enforce the rules you can write down, and people should handle the parts that require taste and product knowledge. A worked example: a team that added a submit-time Flow checking for missing categories and dead links cut their reviewer rejection volume noticeably, because the drafts that used to bounce on trivial issues never reached a reviewer in the first place.
Set up a Knowledge article review gate
Set up a review gate so finished drafts are approved before anyone can publish them. This configures a standard Approval Process on the Knowledge object; a Flow-built approval is the modern alternative when you need conditional routing.
- Plan the review rules
Decide who reviews what before touching setup. Write a short review checklist (accuracy, tone, Data Category, links, duplicates) and map which article conditions route to which reviewers.
- Create the Approval Process
In Setup, build an Approval Process on the Knowledge object. Define entry criteria for which drafts need approval and add one or more approval steps that assign the right reviewers.
- Set the final approval action to keep the record editable
Choose a final approval action that leaves the approved draft editable rather than locked, because Salesforce does not publish at the end of approval. That keeps the draft ready for a publisher to act on.
- Add pre-submit automation (optional)
Build a Flow that runs on submit to block drafts with missing Data Categories, empty bodies, or broken links, so reviewers only see drafts that already clear the mechanical checks.
- Test the submit, approve, publish path
As an author, submit a draft for approval. As a reviewer, approve it and confirm the Approval History related list updates. Then click Publish and verify the article goes online.
The conditions that decide whether a given draft enters the approval process at all, for example only articles in a certain Data Category.
The reviewer or queue that receives the submitted draft. Route by Data Category, author seniority, or topic so the right expert sees each article.
The action that fires when approval completes. Choose one that keeps the record editable so a publisher can act, since approval never auto-publishes.
Appears on the article once an Approval Process is enabled. It records who approved or rejected each draft and when, giving you the audit trail.
- Approval is not publication. After the approval completes, a user must still click Publish for the article to go online.
- Submitting a draft for approval locks the record, so authors cannot keep editing while a reviewer reads it; plan the handoff around that lock.
- A user with only read access can publish a draft once its approval is complete, which is intentional but worth confirming against your access model.
- If you expect the article to auto-publish at the end of approval, publishers can get stuck; a final action that keeps the record editable is the recommended choice.
Prefer this walkthrough as its own page? How to Article Review in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Article Review.
Hands-on resources to go deeper on Article Review.
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 Review step in Salesforce Knowledge?
Q2. What can a reviewer do during an Article Review step?
Q3. Why do mature Knowledge programs balance Article Review rigor against publication speed?
Discussion
Loading discussion…