Problem
Articles in Knowledge currently support only two states: Live and Draft. There's no state for content that is retired but not deleted — old articles we no longer want live, but might need to reinstate later (e.g., seasonal content, deprecated-then-reintroduced features, content pending a compliance/legal review, or articles kept for historical reference).
Right now the only way to handle this is to leave the article as Draft, which is the wrong tool for the job:
- Draft conflates two unrelated things. Draft is meant to represent work in progress toward publishing — a staged revision or a not-yet-finished article. Using it to mean retired content pollutes the Drafts list with old, dead articles, making it harder for writers to find their actual in-progress work.
- No way to distinguish "about to be published" from "parked indefinitely." There's no filter, or view that separates a draft that's one edit away from going live from one that's been sitting untouched for two years because we don't want to delete it outright.
- Search/reporting noise. Draft articles still show up in internal article-management views and counts (total articles, articles by collection, etc.) alongside real drafts, making it harder to audit what's actually being worked on vs. what's just parked.
- Reversibility isn't explicit. Deleting an article is intentionally destructive; draft doesn't communicate that this content was deliberately taken down with intent to possibly restore it. There's no clear "why is this here" signal for teammates who encounter it later.
Proposed solution
Add a third article state — Archived — alongside Live and Draft:
- Behavior: Archived articles are automatically unpublished (removed from the Help Center, search, and Fin/Copilot indexing) and excluded from the default Drafts view.
- Reversible: A one-click "Restore" or "Unarchive" action returns the article to Draft (not directly back to Live, to force a review step before republishing).
- Distinct list/filter: A separate "Archived" tab or filter in Knowledge, so archived content doesn't clutter the main article list, draft list, or collection counts.
- Retains full content and version history: unlike deletion, nothing is lost — title, body, translations, tags, and past versions stay intact.
- Metadata on archive: capture who archived it and when (and ideally an optional reason/note field), for audit purposes.
- Bulk action support: ability to archive/restore multiple articles at once, since this is often a cleanup exercise across dozens of old articles.
- API/webhook parity: expose the archived state via the Articles API (
state: archived) and via webhooks, so it can be scripted/audited, not just a UI toggle.
Why this matters
Content teams need a middle ground between "live" and "gone forever." Deletion is too destructive for content that has re-use value; draft is semantically wrong and creates workflow confusion. An explicit archive state solves both problems with minimal added complexity, and mirrors patterns already common in other CMS/knowledge tools (Notion, Confluence, Zendesk Guide all support some form of archive distinct from draft).