Editorial illustration; the workflow and interface are representative and are not a live Drupal installation.
Publishing is easy when one person writes and approves every page. It becomes less comfortable when subject experts, editors, legal reviewers and publishers all work on the same Drupal site. Giving everyone permission to publish may be fast, but it removes an important check. Asking everyone to email documents around creates a different problem: nobody knows which copy is current.
Drupal’s Content Moderation module adds states and transitions around revisions. The important idea is that a live version can remain visible while a newer revision is being edited and reviewed. That gives a team a controlled path from draft to public content without hiding the current page from visitors.
Summary
- Content Moderation expands the simple published/unpublished model into a workflow of states and transitions.
- Keep the live revision separate from pending edits, and assign permissions by responsibility.
- Test every content type, preview path and publishing transition before enabling the workflow widely.
- Do not add moderation to a one-person site unless the review requirement justifies the extra process.
What the core module does
Drupal’s official documentation describes Content Moderation as a way to expand the published and unpublished states for content. In practice, a content type can use a workflow such as Draft, In review, Approved and Published. Editors create a new revision while visitors continue to see the latest approved version.
The module is about workflow control, not automatically making content accurate. A team still needs a clear definition for each state, a reviewer who understands the subject, and a decision about what happens when a revision is rejected or sent back for changes.
Design the workflow before clicking settings
Start with the editorial decision, not the labels. Ask:
- Who may create a draft?
- Who may move it to review?
- Who checks facts, links, images and accessibility?
- Who may approve and publish?
- Can the author publish their own work?
- What happens to an urgent correction?
- How will scheduled or translated content be handled?
Keep the first workflow small. “Draft → Review → Published” may be enough. Add “Legal review” or “Scheduled” only when the team can explain why that state exists and who owns it.
A safe setup workflow
1. Choose the content types
Begin with one content type that genuinely needs review, such as public news or policy pages. Do not enable moderation for every type without checking how it affects administrative forms, integrations and existing revisions.
2. Enable revisions and moderation deliberately
Content moderation relies on revisions. Confirm the content type creates new revisions and identify which version is considered live. Make a written note of the current state before changing an established site.
3. Define states in ordinary language
State names should describe a decision, not a vague feeling. “Needs review” tells an editor what to do next. “Almost ready” does not. Document the required checks under each state so a new editor does not have to infer the rules.
4. Map transitions to roles
A transition is an allowed move, such as Draft to In review or Approved to Published. Grant only the permissions needed for each role. An author may create and submit a draft; a reviewer may approve content; a publisher may release it. Test with real non-administrator accounts because administrator access can hide permission mistakes.
5. Test the live-versus-pending behaviour
Edit an already published page and save a pending revision. Open the public URL in a separate browser session. Confirm visitors still see the approved content while the editor can see the pending version in the administrative interface.
6. Test rejection and correction
Send a revision back to the author and verify that the reason is visible somewhere your team actually checks. A workflow that only handles approval is incomplete; real editorial work includes corrections, abandoned drafts and changes requested by reviewers.
7. Check previews and related systems
Test preview links, search indexing, menus, APIs, caching, translations, redirects and any moderation dashboard. Pending content should not accidentally appear in public listings or search results. The exact behaviour depends on the Drupal version, contributed modules and site customisations, so verify it on the project rather than assuming.
8. Write the operating rule
Put the workflow guide next to the editorial handbook. Explain who reviews what, how urgent fixes are handled, and what evidence belongs in a revision log. A technically correct workflow still fails if the team uses email or chat as an unofficial bypass.
A realistic example
An organisation publishes a monthly service announcement. The communications editor creates a revision and moves it to In review. A subject expert checks dates and links, then returns it with one correction. The editor updates the same revision and submits it again. A publisher confirms the final text, moves it to Published, and records the release time in the change log.
Meanwhile, visitors continue to see the previous approved announcement. This is the practical benefit: editing can continue without exposing incomplete work or forcing the team to remove the live page.
When Content Moderation is not the right answer
A one-person blog that has no approval requirement may gain little from a multi-state workflow. It introduces permissions, revision decisions and training. If the real problem is poor backups, unclear ownership or slow publishing, moderation will not solve those problems.
Likewise, do not install a contributed module just because it promises a moderation dashboard. Check its maintenance status, Drupal compatibility and security-advisory coverage. Drupal.org marks project information such as supported versions and maintenance status, and those details can change; review them before adding a dependency.
Mistakes to avoid
- Creating too many states before the team has used one complete workflow.
- Giving every editor the publish transition “temporarily” and never reviewing it.
- Testing only as an administrator.
- Forgetting that revisions can contain sensitive information.
- Assuming a preview URL is safe to share publicly.
- Enabling moderation without deciding how translations, scheduled posts or urgent corrections work.
My Take
Good moderation makes responsibility visible without turning publishing into bureaucracy. I prefer a short workflow with clear transitions over a sophisticated diagram that nobody understands. The best test is not whether an administrator can publish; it is whether an ordinary editor can complete the correct path and recover gracefully when a reviewer asks for changes.
Bottom Line
Use Drupal Content Moderation when multiple people need to edit, review and publish without exposing unfinished revisions. Start with one content type, define the states in plain language, assign narrow permissions, test with real roles and document the operating rule. Add complexity only when the editorial risk is real and measurable.