Archived Article
An Archived Article is a Salesforce Knowledge article whose published version has been retired from active use but kept in the org.
Definition
An Archived Article is a Salesforce Knowledge article whose published version has been retired from active use but kept in the org. Archiving sets the PublishStatus field on the KnowledgeArticleVersion record to Archived. The article drops out of Knowledge search results, the agent Knowledge sidebar, and any Experience Cloud help center, yet it stays in the database with its full content, version history, author, and metadata intact.
Archiving sits between publishing and deleting. Published content has a natural lifecycle: product notes go stale, procedures get superseded, and macros stop matching the current release. Deleting throws the article away, while archiving preserves it for audit, legal hold, and possible reinstatement. Only users with the right Knowledge permissions can find or restore an archived article, so agents and customers never stumble onto outdated answers during normal work.
How archiving fits the Knowledge lifecycle
Where Archived sits among publish statuses
Every Knowledge article version carries a PublishStatus value, and the three states are Draft, Online, and Archived. Draft is the working copy that authors edit and route through review. Online is the live version that agents and customers can read in search, the Knowledge component, and help center sites. Archived is the retired version that has left active circulation but remains stored. A single article can have versions in more than one state at once. You can have one Online version that customers read while a newer Draft sits in review. Archiving is a deliberate action taken on the live version, not something Salesforce does on its own. When you archive the live article, its current version moves to Archived, and the article no longer has an Online version until someone restores or republishes it. Because the status lives on KnowledgeArticleVersion, you can query it directly with SOQL, for example PublishStatus equals Archived, which is how reports and integrations find retired content.
What actually changes when you archive
Archiving flips the live version to Archived and pulls it out of every reader-facing surface. It disappears from Knowledge search, the Service Console Knowledge sidebar, the Lightning Knowledge component, and Experience Cloud help centers. The record itself does not move to the Recycle Bin and has no scheduled purge, so the content persists until someone deletes it on purpose. Version history is the part people care about most. The archived version keeps who wrote it, when it went live, and which earlier versions existed. If the article had several published versions over its life, archiving the primary version retires the active one while the historical versions stay attached to the same article record. This is why regulated teams favor archiving over deletion. Keeping the exact answer a customer was once given can itself be a compliance requirement. The archive is the durable record of what the company told people at a point in time, even after the guidance has changed.
Who can see and manage archived content
Visibility is permission-gated, which is the whole point of the Archived state. Standard agents and customers cannot see archived articles. Users need the Manage Articles permission, and in Lightning Knowledge the View Archived Articles permission is enabled automatically inside the relevant permission sets. Without those, the article is effectively invisible. Salesforce tightened this in the Winter 20 release with permissions that fine-tune access to Draft and Archived articles separately. That lets you grant a compliance reviewer the ability to read archived content without also handing them edit rights on drafts. In Lightning Experience, managers find archived articles by filtering the article list view by publication status. Data category visibility still applies on top of the permission, so a user only sees archived articles in the categories they are entitled to. Plan these settings before you start archiving at scale, because the gap between who archives and who can later read the archive causes most of the confusion teams run into.
Archive versus delete
The two actions look similar but behave very differently. Deleting an article removes it from the org. Deleted articles go to the Recycle Bin and can be restored for a limited window, after which they are gone permanently. Archiving removes the article from active use but keeps it indefinitely with no automatic cleanup. Choose based on intent. Delete when the article was a mistake, a duplicate, or content that should never have existed and carries no record-keeping value. Archive when the information was correct once and may need to be referenced, audited, or brought back. A superseded compliance procedure is a classic archive case, because you may have to prove later what the approved steps were on a given date. A test article created during setup is a delete case. Getting this distinction right keeps your Knowledge base clean without throwing away history you might be legally obligated to retain.
Restoring and republishing
Archived articles are not a dead end. A Knowledge manager can restore an archived article, which returns it to Draft so reviewers can work on it. Often the reason it was archived was outdated information, so the restore step is the natural moment to update the content before it goes live again. Once the draft is ready, publishing it creates a fresh Online version. Restoring reuses the article identifier, so inbound links from Cases, internal references, and external systems keep resolving to the same article. The REST API exposes this directly. You restore an archived version, and if you do not name a specific version number, it restores the latest archived version. Approvals add a wrinkle worth knowing: approval processes are not available for archiving, and workflow rules do not run on the archive action either. So if your org gates publishing behind an approval, that approval applies when you republish the restored draft, not at the moment of archiving.
Scheduling, automation, and reporting
You do not have to archive only by hand. The Knowledge REST API accepts an archiveScheduleDate, so you can set a future date for an article to archive itself. That is useful for content with a known expiry, such as a seasonal promotion or a policy that sunsets on a fixed day. For larger bases, teams build Flows or Apex that archive articles meeting conditions like no views in a quarter or an age past eighteen months. Pair any automation with a heads-up. The friction point in most Knowledge programs is silent archiving, where an article vanishes and the owner finds out from an angry agent. A grace-period notification a week or two ahead lets authors object before the archive lands. On the reporting side, custom reports on KnowledgeArticleVersion filtered to PublishStatus equals Archived surface the archive trail. Useful views include articles archived per quarter and articles archived then restored, which together measure content hygiene and flag topics that keep going stale.
How to archive a Knowledge article
Archiving is an article action a Knowledge manager runs against the live version of an article in Lightning Experience. You need the Manage Articles permission, and the action is final for that version until someone restores it.
- Open the article in the Knowledge list view
Go to the Knowledge tab or app, switch to a list view such as Published Articles, and open the article you want to retire. Confirm you are on the current Online version.
- Choose the Archive action
From the article actions menu, select Archive. Lightning shows a confirmation because archiving removes the version from search and every reader-facing surface right away.
- Decide between immediate and scheduled
Archive now to retire it instantly, or use the API archiveScheduleDate to set a future archive date for content with a known expiry. Scheduling avoids manual follow-up on time-bound articles.
- Verify and record the reason
Reload the list view filtered by Archived to confirm the article moved. Note the archive reason in a custom field so future managers know why the content left circulation.
Required to run the Archive action and to view archived content afterward; granted via profile or permission set.
Auto-enabled in Lightning Knowledge permission sets; lets a user read archived articles without necessarily editing drafts.
Optional date passed through the Knowledge REST API to archive the primary version automatically on a future day.
Still applies to archived articles, so users only see retired content in the categories their settings permit.
- Approval processes and workflow rules do not apply to the archive action; approvals only gate the later republish.
- Archived articles do not go to the Recycle Bin and have no automatic purge, so cleanup is always a deliberate delete.
- Silent archiving erodes author trust; warn the content owner before the archive lands, especially with auto-archive automation.
- If data categories or layouts changed after archiving, a restored article may need manual fixes before it republishes cleanly.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Archived Article.
Hands-on resources to go deeper on Archived 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 happens when an article is archived in Salesforce Knowledge?
Q2. Why archive an article instead of deleting it?
Q3. What is a common reason to archive articles?
Discussion
Loading discussion…