Drupalwoo ☉

Using Drupal Workflows for content approval

Drupal’s Workflows module gives Drupal sites a configurable way to control how content moves from an author to a reviewer and, finally, to a publisher. Instead of relying on an informal email chain or a shared checkbox, a content workflow assigns each item an explicit status and exposes only the actions appropriate to that stage. The result is easier for editors to understand and more consistent for organisations that need accountable approval.

Content Moderation supplies the editorial interface around those workflow definitions. Together, they suit policy pages, campaign material, reports, member resources and other Drupal content that may need technical, editorial or legal review. A sensible setup reflects the decisions made by the team without forcing every article through a long administrative chain. It should also remain simple enough that an editor in Melbourne can move work forward while a reviewer in Sydney checks the current revision.

Build a practical approval path

In Drupal 10 and 11, Workflows is a core module, while Content Moderation is the companion module that turns workflow states and transitions into an editorial experience. Enable the modules you need, create the content type first, and then define a workflow for it. The same workflow can be reused for related content types when they genuinely share one approval policy, although separate workflows often make ownership and reporting clearer.

Give the workflow a plain-language name, such as Campaign resource approval, and add only the states the team needs to distinguish. A common path is Draft, In review, Approved and Published. Draft is the default state for new content, while Published represents content that has completed its final transition. The editorial operation determines what the public sees; changing an item’s workflow state alone does not make it visible on the public website.

Transitions describe who can move content and what that action means. Add transitions from Draft to In review, from In review to Draft for changes requested, from In review to Approved, and from Approved to Published. A simpler alternative is to let the publisher move approved content directly to Published without a separate Approved state. Use labels that match the team’s language, such as Submit for review, Return to author and Publish, because editors will see those labels in the interface.

Set roles and transition permissions

Workflow access should mirror responsibility. An author may submit a draft, a subject-matter reviewer may approve factual accuracy, and a publisher may perform the final publication action. Assign roles when defining each transition instead of giving every authenticated user access to every step. Role selection on a transition and Drupal’s broader permissions are separate controls: reviewers also need suitable access to view the unpublished node and its moderation controls.

Keep separation meaningful rather than ceremonial. If the same person can write, approve and publish, the workflow still records states but offers little independent oversight. That may be acceptable for a small site, yet it should be a conscious choice. Larger Drupal implementations common among Australian government agencies, universities and not-for-profits often have different editorial, subject-expert and publishing responsibilities, so role boundaries should reflect those duties rather than job titles alone.

Timeouts and availability also belong in access design. Teams spread across Sydney, Melbourne and Brisbane may hand work over during the eastern Australian working day, while a Perth reviewer can be two hours behind Eastern Standard Time. A late-arvo handoff can therefore reach a reviewer after their normal finish time, making a clear Return to author action more useful than an informal request made in chat. For related Drupal configuration ideas, David Duval’s Drupal notes offer useful context beyond the workflow screen.

Keep workflow state separate from access

A workflow state describes editorial progress, not audience visibility. Node access determines who can see an unpublished entity, while module permissions and workflow roles determine who may administer, review or publish it. Treating those mechanisms as interchangeable can expose a draft or allow an editor to approve content they cannot view.

Mechanism What it controls Typical approval setting Important limitation
Workflow Stores the current editorial state and available transitions Draft moves to review, then approval and publication Does not itself grant access to unpublished content
Content Moderation Adds moderation controls and editorial status to the content interface Attach a moderated content type to the chosen workflow Does not replace entity access or an editorial decision
Node access Restricts who may view unpublished entities Authors and assigned reviewers can view their own or relevant drafts Visibility is not the same as permission to publish
Roles and permissions Controls administrative and content operations Reviewers approve, publishers publish and administrators configure Broad access can bypass intended separation of duties

Content Moderation integrates the workflow with the content form, so editors can see the current state and available transitions in context. Configure node access separately for the audience that must see work in progress, such as authors, reviewers or a private newsroom group. Anonymous visitors normally need access to the published version only, unless a deliberate public preview is required.

Do not grant a broad “view any unpublished content” permission simply to solve a review problem. Give each reviewer the narrowest practical access, and confirm that only intended roles can move an item to Published. The workflow, entity visibility and Drupal permission should reinforce one another; if one of them is too broad, the apparent controls can give false confidence.

Test revisions and real publishing paths

Test the workflow with representative content, including short announcements, long reports, pages with many reviewers and an item that must be returned for corrections. Each user should see only the transitions available to their role. Check that unavailable actions are absent or blocked, that a returned draft retains its revision history and that a successful publish produces the intended URL and public visibility. Include an administrator, since configuration access can reveal problems that an ordinary editor will not encounter.

The relationship between revisions and approval deserves special attention. Core workflow state is normally associated with the entity rather than securely bound to one particular revision. If approved content is edited, the change may not send it back to Draft automatically. Configure revisions to retain the versions needed by your policy, require a fresh review after substantive edits, and make the moderation status visible so a publisher knows which revision was approved. Core revisions help reconstruct content changes, but they are not a complete audit record of every workflow decision.

Australian requirements may add another approval dimension. Where the Privacy Act 1988 and Australian Privacy Principles apply, privacy review can become a named gate before a form or event page goes live. Campaign teams should also check the Spam Act 2003 when their publication supports email marketing, including consent and unsubscribe processes. A Drupal implementation can be technically correct and still need the right owner to sign off these details. A second-person acceptance test or independent Drupal review can expose gaps; requests can be directed to contact Drupalwoo.

Recommendations for dependable approvals

Start with the smallest workflow that reflects genuine organisational decisions. If a page needs only author review and publication, three states are enough. More states add clarity only when they correspond to a distinct handoff, such as accessibility sign-off, privacy review or a formal approval that changes who is accountable.

Document the path, required roles and revision expectations where editors can find them. A short decision record naming the approver, expected response time and circumstances for returning content is often more valuable than a complex diagram. Agree on how urgent releases bypass the standard route, and record that exception instead of allowing an undefined override.