The article lifecycle
An article isn’t a one-shot deliverable. It’s a small piece of living documentation that goes live, ages, gets revisited, and eventually either gets refreshed or retired. Atender’s status field is the spine of that lifecycle — four states that map to the real stages an article passes through.
The four states are detailed in Article statuses. This concept article is about how they connect into a workflow you can actually run as a team.
The five stages
1. Draft — you’re writing
A new article starts as draft. So does an AI-generated first pass from the editor’s AI Writing Assistant. Drafts are invisible to the public, invisible to your AI agents, and free to revise. There’s no cost to leaving an article in draft for a week while you nail the wording.
2. Needs review — someone else’s eyes
When you think the article is ready but want a teammate to sign off, set status to needs-review. It stays hidden from customers and from AI retrieval, but it shows in admin views with a clear flag. This is the right state for:
- AI-generated drafts you want a domain expert to fact-check.
- Articles touching a feature you don’t own, where someone else should approve.
- Updates to a high-stakes article where you’d rather have a second opinion before re-publishing.
3. Published — the article does its job
Moving to published triggers two things at once: the article appears on the public help center, and the embedding pipeline queues a vector index update so AI agents start retrieving from it. Both happen within a minute.
This is the steady state. Most articles spend most of their life here.
4. Needs review again — the article ages
Software changes. Pricing changes. Policies change. An article published nine months ago might describe a workflow that’s been replaced. Atender tracks lastReviewedAt on every article so a future “stale articles” dashboard can surface the ones that haven’t been touched in 90 days.
The intended pattern: every quarter, a teammate walks the stale list, opens each article, and either:
- Confirms it’s still accurate (and the system bumps
lastReviewedAt), or - Flags it as
needs-reviewand rewrites it.
For now, this is a manual cadence — set a quarterly reminder. The dashboard that automates it is on the roadmap.
5. Archived — the article retires
Some articles outlive their feature. When that happens, set status to archived. The article disappears from the public site and from AI retrieval, but the database keeps it. If the underlying feature comes back, restore it; if it doesn’t, the archive preserves the history.
There’s a separate Archive Article button in the editor that does the same thing as setting status to archived — both routes land in the same place.
Why this matters
A help center that’s never reviewed degrades quietly. Articles describing yesterday’s UI sit unchanged, AI agents retrieve them, and customers get bad answers. The lifecycle isn’t bureaucratic — it’s how you keep the corpus honest.
The cheapest version: publish freely, set quarterly reminders to walk the stale list, archive what’s no longer true. Most teams overthink this and end up with a stale help center anyway. A light review cadence with a clear archive habit beats a heavyweight workflow you never actually run.
Where the AI fits
Three of the four statuses keep articles out of AI retrieval (draft, needs-review, archived). Only published articles are embedded and retrievable. This is intentional: an article you’re not confident in shouldn’t reach customers through any surface.
The reverse is also true: if you don’t want AI agents to use an article right now, change the status. Status is the kill switch.