Drupalwoo ☉

Using Drupal’s Workbench Moderation for reliable content workflows

A publishing workflow determines how content moves from an editor’s first draft to a page that visitors can trust. In Drupal, moderation tools provide a controlled path through drafting, review, approval, publication and retirement. This is useful for a small business site, a university department, a government service or a media team managing hundreds of pages.

The name Workbench Moderation is often used broadly, although Drupal’s current approach is based on the Content Moderation module in core. Workbench Moderation was widely used on Drupal 7 and in earlier Drupal 8 projects, while newer installations generally use Content Moderation together with Workflows. Understanding that distinction helps administrators choose the right configuration and avoid following instructions intended for an older Drupal version.

How moderation fits into Drupal

Drupal moderation separates the editing process from the public version of a page. An author can create a new revision, save it as a draft and send it for review without replacing the version visitors currently see. A reviewer can then approve that revision, while the published copy remains available until the approval transition occurs.

This revision-based model is valuable when several people work on the same content. A communications officer might prepare a page, a subject specialist might check the facts, and an editor might approve the final wording. Each person can have a specific permission instead of receiving broad administrative access.

The workflow is attached to an entity type and its bundles. Basic pages, news articles, landing pages and custom content types can use different workflows when their approval requirements differ. A short news update may need one review step, while a public policy page may need legal, accessibility and executive approval.

On current Drupal sites, administrators usually enable Workflows and Content Moderation, then create a workflow from Configuration > Workflow > Workflows. On a legacy Drupal 7 site, the Workbench suite and Workbench Moderation may still be the correct tools. Check the Drupal core version and existing modules before changing the system.

Designing useful states and transitions

A workflow state describes where a revision currently sits. Common states include Draft, In review, Approved, Published and Archived. States should describe editorial responsibility clearly rather than reflecting every possible task. A complicated list can make the moderation screen harder to understand and encourage users to bypass the process.

Transitions describe the permitted movement between states. For example, an author might be allowed to move Draft to In review, a reviewer might move In review to Approved, and a publisher might move Approved to Published. A transition is different from a state: “Submit for review” is an action, while “In review” is the resulting condition.

A practical workflow for a community organisation might look like this:

Avoid creating a state for every department unless that department has a real decision to make. If content must pass through legal review, create a meaningful legal-review state or transition. If a team merely wants to record that someone looked at the page, a checklist or editorial note may be more suitable.

Matching permissions to editorial roles

Permissions are where a workflow becomes a governance system. A site may have roles such as Author, Reviewer, Publisher, Content Manager and Administrator. Each role should receive the smallest set of permissions needed to perform its work. Drupal’s permission system can control who creates content, edits content, views revisions, uses transitions and administers workflows.

Authors commonly create and edit their own drafts, then use a transition such as Submit for review. Reviewers need access to the relevant revisions and the permission to move content from In review to Approved. Publishers may be responsible for the final transition to Published. A content manager may also archive outdated pages and correct workflow exceptions.

The distinction between editing a published entity and creating a new revision deserves careful testing. A user may be able to edit content but still lack the permission to publish it. This allows a communications team to update wording while reserving public release for an authorised publisher.

Use separate user accounts when testing permissions. An administrator can often perform every action, which hides problems that ordinary users will encounter. Create a sample author, reviewer and publisher account, then test the complete path from a blank draft to a published revision.

Australian organisations often need a clear audit trail for public information. A Canberra government team, a council in Queensland or a health service in Victoria may need to show who approved a page and when it became public. Drupal’s revision history and moderation state provide useful evidence, but the organisation should also document who owns each workflow step.

Configuring the workflow in practice

Begin by identifying the content types that need moderation. Enable moderation for the relevant bundles instead of applying it indiscriminately to every entity. A simple internal content type may not need approval, while a public service page, campaign landing page or emergency information page probably does.

After creating the workflow, assign states and transitions. Then map the transitions to roles through permissions. Review the settings for “Create new revision” and confirm that editorial changes do not unexpectedly alter the live version. The exact interface varies between Drupal releases, so verify labels and configuration paths in the version installed on the site.

Editorial need Suitable state or transition Typical permission holder Verification point
Start new work Draft Author The revision is private or limited to permitted users
Request a check Submit for review Author The item appears in the reviewer’s queue
Check content In review Reviewer The reviewer can inspect the complete revision
Confirm readiness Approve Senior reviewer or content manager Required factual and accessibility checks are complete
Release publicly Publish Publisher The approved revision becomes the live version
Remove outdated information Archive Content manager Visitors no longer receive the page as current content

Create a test node for every moderated content type and move it through each transition. Check the result as an anonymous visitor, an authenticated editor and a reviewer. Pay attention to previews, revision labels, moderation tabs and the page displayed by menus or Views. A workflow is incomplete if the state changes correctly but the editorial team cannot find the content waiting for action.

Views can support moderation queues by filtering content on moderation state, author, content type or changed date. A reviewer dashboard might display all items in In review, sorted by oldest first. For teams working across Australian time zones, displaying the changed date and editor name can reduce confusion when colleagues in Perth, Sydney and Brisbane hand work to one another.

Handling revisions, translations and scheduled publishing

Moderation depends on revisions, so revision settings should be treated as part of the workflow design. Each approval action should apply to the intended revision. Editors need to know whether they are viewing the current draft, the live revision or an older revision from the history screen.

When content is translated, moderation can become more complex. A source-language page may be approved while its translated version remains in draft. Decide whether each translation can move through the workflow independently or whether publication requires all language versions to reach an approved state. Test translated aliases, menus and referenced media before releasing the page.

Scheduled publication requires additional planning. Core moderation controls state changes, but automatic publishing at a future time may require another module or an integration with a deployment process. Modules such as Scheduler may be used depending on the Drupal version and project requirements. Test scheduled transitions around daylight saving changes, especially when editors work between Melbourne or Sydney and Western Australia.

Time zones should be configured deliberately. A newsroom in Sydney may plan a release in AEDT, while a contributor in Perth reads the schedule in AWST. Store and display dates consistently, document the business time zone and test dates around the start and end of daylight saving. This avoids a page appearing early or late during a major campaign.

Building a review process people will use

A technically correct workflow can still fail if its labels and responsibilities are unclear. “Needs work” may be understandable to one team but ambiguous to another. Use action-oriented transition labels such as Submit for review, Request changes, Approve for publication and Archive page. Add help text where users need to understand the next step.

Reviewers should have a practical queue rather than searching through all content. A View filtered by moderation state is often enough for a small team. Larger sites may add filters for department, content type, owner, publication date or campaign. A useful queue should show the title, current state, author, last update and a direct link to review the revision.

The review checklist should match the content’s risk. For a local events page, the reviewer may check dates, venue details and contact information. For an Australian financial service, the check may include regulatory wording, accessible documents and links to privacy information. For content referring to Aboriginal and Torres Strait Islander communities, the organisation should follow its own cultural review and permissions process rather than assuming a generic editorial check is sufficient.

Notifications can help reviewers notice new work, but excessive email creates noise. Use notifications for important transitions and keep the authoritative queue inside Drupal. Agree on response times, escalation paths and ownership for urgent content. A team publishing bushfire information or public transport changes needs a faster process than a team maintaining evergreen history pages.

Preventing common workflow problems

One common mistake is giving every editor permission to publish. This makes the workflow appear successful while removing the approval control it was created to provide. Review role permissions regularly, especially after adding new modules or importing configuration from another environment.

Another problem is leaving revisions in review indefinitely. Create a report for stale moderated content, perhaps filtering items that have not changed for seven or fourteen days. A content manager can then contact the owner, reject the work or archive it. The best retention period depends on the organisation’s records policy and content type.

Avoid relying on unpublished content as a substitute for moderation. An unpublished node may be inaccessible to the public, but it does not necessarily provide a clear approval history or a structured route between roles. Use moderation states for editorial decisions and access controls for confidentiality.

Review custom code and integrations after enabling moderation. Search, JSON:API consumers, newsletters, translation systems and external publishing tools may need to request the correct revision or filter by published status. A frontend that displays the latest revision without checking publication status can accidentally expose draft material.

Maintaining and improving the workflow

Treat workflow configuration as code or managed configuration where possible. Export changes with Drupal Configuration Management, review them in version control and deploy them through development, staging and production environments. Do not test major permission changes directly on a busy live site.

Audit the process after launch. Ask which states are being used, where items wait, whether reviewers can find their queues and whether publishers understand the final release step. Drupal’s logs, revision history and content reports can reveal whether content is being edited repeatedly, abandoned in review or published without the expected checks.

Keep the workflow documentation short and operational. Explain who can create drafts, who reviews them, what each transition means and what to do when a page must be corrected urgently. Include screenshots only when the interface is stable; otherwise, describe the menu path and the expected state.

For modern Drupal projects, Content Moderation is usually the preferred replacement for older Workbench Moderation configurations. A migration should preserve editorial intent rather than reproduce every historical state. Map old states to a smaller, clearer workflow, test revision behaviour and train the team before switching production content. With sensible states, precise permissions and a visible review queue, Drupal can support reliable publishing without turning everyday editing into an administrative obstacle.