A content lifecycle is the set of states and decisions that keeps information useful over time. Define who can move an item forward, what they check and what happens when a published item becomes inaccurate. A small, explicit workflow is easier to operate than a long list of ambiguous statuses.
Give each state a clear meaning
Start with one content type and the people who already work on it. Separate the state of the public version from the state of a proposed revision. A published guide may remain available while its next revision is being reviewed.
| State | Responsible role | Evidence needed for the next step |
|---|---|---|
| Draft | Author | Purpose, source facts and affected dependencies recorded. |
| In review | Reviewer | Factual, editorial and required specialist checks resolved. |
| Approved | Accountable owner | Exact version approved; release timing and dependencies agreed. |
| Published | Publisher | Public page, links, downloads and access verified. |
| Due for review | Content owner | A recorded check, revision task or retirement decision. |
| Superseded or retired | Owner and publisher | Replacement route and retention decision documented. |
“Due for review” can be a flag on a published item rather than a separate CMS state. Keep the model understandable to the team. Drupal's content moderation documentation illustrates how a live published version can coexist with a working copy. Check your platform's revision and transition behavior before implementing the same pattern.
Make approval specific to a version
The author proposes changes. The subject owner verifies the facts. A designated publisher releases the approved version. A small organization may combine roles, but consequential changes still benefit from a second reader. Restrict publishing and workflow configuration to people with those responsibilities.
Record the content identifier, revision, reviewer, decision and timestamp. If the author changes a consequential fact after approval, send that revision through the relevant review again. An approval on an earlier version should not silently cover a new promise, deadline or eligibility rule.
Define an urgent correction route before it is needed: who can authorize the repair, what evidence is required and when a retrospective review must occur. Urgency can shorten a queue while preserving accountability.
Follow a policy page through a change
Use change triggers as well as dates
Set review frequency according to the likelihood and consequence of change. Prices, service locations and time-limited procedures need different attention from stable background explanations. A scheduled review is a backstop. A changed source policy, broken download, new product version or repeated reader complaint should trigger work immediately.
A review should produce evidence: which facts and links were checked, what changed and who checked them. Record “reviewed, no change needed” separately from “updated.” Updating a date without checking the substance weakens the record.
Keep a queue of overdue items with owners and consequences. Escalate an ownerless page to the person accountable for the service. If the information is actively misleading, agree a correction, warning or withdrawal promptly instead of waiting for the next routine cycle.
Retire content deliberately
Before withdrawing a page, inspect incoming links, navigation, downloads, translations and embedded copies. Identify a useful replacement if one exists. Use a redirect only where the destination serves the same reader need; otherwise provide an appropriate removal or historical treatment.
The public page's retirement and the underlying record's disposition are different decisions. Consult the records-management guide and applicable policy before removing controlled history or evidence. Record who made the retirement decision, why, and where readers should go next.
Download the lifecycle and review-log template. It includes the fictional example, blank fields for a live version and proposed revision, and a review checklist. Test the workflow on three real items before extending it to the whole library.