University websites are published by almost everyone. Faculties, departments, admissions, research centres and student services all put pages live, usually through dozens of contributors whose main job is not the web. Without a defined route, that produces typos, off-brand pages, information nobody remembered to retire, and occasionally something sensitive appearing before anyone with authority has read it.
A content approval workflow gives every page the same route to the public. It starts as a draft, waits for a named reviewer, and goes live once that reviewer signs off. Drupal handles this with two core modules and no paid add-ons. This article covers how those modules fit together, how to size the process to an institution, what changes on multilingual sites, and the configuration details that decide whether a review queue keeps moving or quietly stalls.
Why university publishing needs a review step
A university is a large decentralised publisher, and that combination is what makes editorial control difficult. Contributors sit in every faculty and unit with very different levels of web training, while central communications and IT stay accountable for accuracy, brand, accessibility and, on admissions or policy pages, legal and reputational risk.
The institutions running the largest Drupal estates in higher education are built around exactly this problem. Harvard, Yale, Stanford and Duke each operate a named institutional Drupal platform that departments and research groups publish into rather than a scatter of unrelated sites, and Harvard's own platform documentation lists content publishing and user management side by side as core features. Once hundreds of units share one platform, deciding who may publish stops being a detail and becomes the platform's central governance question.
The point is not to slow contributors down. It is to let a first-time faculty author draft freely while someone trained confirms the page meets standards before anyone outside the institution sees it.
How it works: Workflows and Content Moderation
By default a Drupal page has two conditions, published or unpublished, which is not enough to describe a review process. Two core modules extend that.
Workflows defines the states content can occupy and the transitions between them. It is the abstract shape of your process and nothing more. On its own it does nothing at all, and installing it alone produces a screen telling you no workflow types are available.
Content Moderation supplies that workflow type. It attaches the workflow to real content, such as specific content types, and ties every transition to its own permission so only the intended roles can move a page forward.
Both are core modules, and their stabilisation history is worth knowing because it is often reported loosely. Content Moderation entered core as an experimental module in Drupal 8.2 and Workflows followed in 8.3. Workflows was marked stable in 8.4 while Content Moderation was still in beta, and Content Moderation reached stable in Drupal 8.5.0. Content Moderation requires Drupal 8.4 or later. On Drupal 10 and 11 both are simply part of core, enabled from the Extend page. The official Content Moderation documentation walks through the setup.
States, transitions and the permissions that enforce them
Three concepts sit underneath every Drupal workflow. States are the conditions content can occupy. Transitions are the permitted moves between them, and they are directional, so a page cannot jump from draft to archived unless you allow it. Revisions are the versioned history underneath. Drupal supports pending revisions, which means an editor can prepare a new version of a page that is already live without any of that work appearing publicly until it is approved.
Permissions are what turn this from a diagram into a control. Drupal creates a separate permission for each transition, so the right to use the Publish transition can be granted to reviewers and withheld from contributors. That single mechanism is the entire approval chain.
Enabling Content Moderation creates a default Editorial workflow containing Draft, Published and Archived. One detail catches people out: that default workflow is only created automatically if the site was installed from the standard installation profile. On a minimal or custom profile you build it yourself.
A workable university state set usually extends the default slightly.
| State | What it means | Moved into it by |
|---|---|---|
| Draft | Being written or revised, not visible to the public | Any contributor |
| Needs review | Submitted and waiting for a reviewer | Any contributor |
| Needs work | Returned to the author with feedback | Reviewers |
| Published | Live on the site | Reviewers and administrators |
| Archived | Retired from the site but retained | Administrators |
One consequence of the default workflow surprises most new editors: there is no unpublish button. To take a live page down you set the published revision to Archived.
Sizing the workflow to a university
In practice a university maps this onto a small set of roles rather than a large one.
| Role | What it can do | Usually held by |
|---|---|---|
| Contributor | Create and edit drafts, submit content for review. No publish transition. | Faculty and department staff |
| Reviewer | Review, edit, publish or return content. Needs permission to view unpublished and latest-version content. | Trained faculty editors or central web team |
| Administrator | Everything a reviewer can do, plus assigning roles and configuring workflows. | Central IT or communications |
The guiding principle is least privilege. Someone maintaining course pages does not need site configuration or user management, and keeping that role narrow protects the platform as a whole.
Drupal allows several workflows on one site, each applied to different content types, and this is where the model becomes genuinely useful at university scale. Ordinary department pages take the short route. Admissions regulations, press releases and legal notices route through an extra approval state that ordinary pages skip. You apply as much oversight as each kind of content actually warrants instead of forcing everything through one process.
This is the editorial counterpart to architectural governance, and on large estates the two work together. Our guide to managing university websites with Drupal multisite covers the architectural half.
Multilingual sites: reviewing each translation separately
Drupal 8.5 added support for translations to be moderated independently, and on a bilingual university site that changes the shape of the process.
Each translation carries its own moderation state. The English version of a page can be live while another language sits in review, or the reverse. That matters because a single reviewer rarely has the language competence to approve every version, and a reviewer approving content they cannot fully read is a rubber stamp rather than a control.
Settle language ownership before configuring anything. Decide who reviews which language, and decide what visitors should see when one translation is approved and another is not. Independent moderation means a page can legitimately be live in one language and absent in another, so confirm that the fallback behaviour matches what you intend.
Configuration details that stall a review queue
Most approval workflows that fail do not fail on design. They fail on small configuration details that leave the queue invisible or unusable.
- Reviewers cannot see what they are meant to review. Transition permissions alone are not enough. Reviewers also need permission to view the latest version and to view any unpublished content. Without those, the review queue simply looks empty.
- Drafts stack and publish together. Draft revisions are cumulative, so each one builds on the last rather than standing alone. If several people save drafts of the same page before anyone reviews it, publishing does not release one of those changes. It releases all of them at once, which is easy to miss on a page with more than one author.
- Content cannot jump straight into review. Transitions are directional, so unless you explicitly define a move from Published to your review state, a contributor updating a live page has to save it as a draft first and submit it second. That transition is easy to leave out when the workflow is designed around new pages rather than edits to existing ones.
- Nobody knows it is their turn. Left to manual checking, content sits in review because no one noticed it arrive. Content Moderation Notifications emails a chosen role or the content author whenever a piece moves between states, and is configured at /admin/config/workflow/notifications. A dashboard listing everything currently in the pipeline covers the rest.
- Reviewers still have to log in. Drupal shows unpublished revisions only to authenticated users holding the right permissions, so a workflow that depends on a busy dean glancing at a page will not work the way it was designed.
When an approval workflow is not worth it
Moderation exists to separate the people who create content from the people who approve it. Where those are the same people, it adds friction without adding oversight.
A site run by one or two trusted editors who all hold publishing rights does not need one, because routing your own work through your own queue slows publishing down for no gain. A workflow also becomes a liability when the chain is longer than the institution can staff. If a page must clear several busy approvers, the queue turns into a bottleneck and contributors start finding ways around it, which leaves the institution with less control than it had before.
The advice that holds up across large institutions is to keep moderation as simple as the risk actually warrants. Start with the states you genuinely need and add a new one only when a real editorial need appears, rather than building process for its own sake. A workflow people route around is worse than no workflow at all.
Two limits are worth knowing before committing. Moderation applies only to revisionable entities, which covers nodes, custom block types and taxonomy terms but not everything on a site. And the platform decision sits underneath all of this; if that is still open, our comparison of Drupal and WordPress for universities covers where each one fits.
Configured with that discipline, content approval stops being an extra layer and becomes part of how the platform works. Faculties and departments contribute broadly, and a dependable check sits in front of anything reaching the public. At Drupart, the Drupal4edu team builds Drupal platforms for universities such as Sabancı University, METU and Yıldız Technical University, where editorial approval rests on the same core foundation described here. Our overview of Drupal in education goes further into why that foundation suits higher education.
Frequently asked questions about Drupal content moderation
Is content moderation part of Drupal core?
Yes. Workflows and Content Moderation are both core modules, enabled from the Extend page, with nothing to buy or download. Workflows was marked stable in Drupal 8.4 and Content Moderation in 8.5.0, and Content Moderation requires Drupal 8.4 or later. Optional extras such as email notifications and moderation dashboards come from contributed modules, but the approval mechanics themselves are built into Drupal.
What is the difference between a state and a transition?
A state is a condition content can be in, such as Draft, Needs review, Published or Archived. A transition is a permitted move from one state to another, such as Publish or Archive. The distinction matters because permissions attach to transitions rather than to states. You control who can advance a page by granting or withholding each transition, so states describe where content currently is and transitions define how, and by whom, it reaches the next step.
Can different content types use different workflows?
Yes, and on a university site this is one of the most useful things you can configure. You can create several workflows and apply each to different content types. A department news item might use a simple draft-to-published route, while an admissions regulation passes through an additional approval state. Each content type then carries only as much oversight as it actually needs.
How do I unpublish a page once moderation is enabled?
Under the default Editorial workflow there is no separate unpublish action. You set the published revision to the Archived state instead, which removes the page from the public site while keeping its revision history intact. Editors used to a simple published toggle usually need this pointed out once, after which it becomes routine.
How do reviewers know when something is waiting for them?
Through Content Moderation Notifications, a contributed module that sends email when content transitions between states. It can notify everyone holding a reviewer role or the content's author, is configured at /admin/config/workflow/notifications, and works alongside core Content Moderation. Paired with a dashboard showing everything currently in the pipeline, it keeps content from sitting in review unnoticed.