Drupal editorial workflows with Content Moderation

Why editorial workflows in Drupal need design before configuration

An editorial team that must review and approve content before it goes live, and sometimes stage a batch of site-wide changes before they reach visitors, is the usual reason to implement the core Workflows and Content Moderation modules together with Workspaces. Workflows defines the states content can hold (for example draft, in review and published) and the transitions between them, Content Moderation applies that model to nodes and other supported entities, and Workspaces lets a set of changes be built and previewed in a separate staging area before it is published as a unit. Teams usually bring in these modules when a single editor publishing directly is no longer acceptable, or when a redesign, campaign or migration needs to be checked as one package. Enabling the modules takes minutes. The hard part is the role and state model that sits behind them: which states exist, which transitions each role may perform, who may move content from review to published, whether editors can see other people's workspaces, and how a change made in a workspace interacts with a scheduled or moderated node. Those decisions are easy to defer and expensive to unwind once content already sits in a state nobody can act on. Before configuring anything, write down each state, its owner, each permitted transition and the roles behind it, then test that model with the editors who will use it. Confirm which Workspaces behaviors apply to the Drupal version you target, since the module set and its interactions have changed across releases.

Drupal core and its contributed modules are licensed under GPL-2.0-or-later, and there is no paid edition of Drupal itself, so the cost of this work sits in configuration, testing and ongoing support rather than in licenses. When you ask a partner for a quote, ask for the state and role design as its own deliverable, a test plan covering each role and transition, and an explicit account of how the workflow will be maintained through core and module updates. Those items, not the module installation, are what determine whether the workflow still works after the first year.

What Content Moderation and Workspaces do in Drupal core

Content Moderation and Workspaces solve different problems. One governs the review path for each piece of content, the other stages several changes together before they go live. Read each card as a capability to confirm in your Drupal version, with the edge of the documentation marked so your team knows what to test before committing to a design.

Moderation states and transitions

Content Moderation lets you define states such as draft, review and published on each moderated content type, then allow transitions between them by role. The transition permissions decide who can send content forward and who can publish it. Check in your version which transitions exist by default, how custom states are added through configuration, and whether a state can be restricted to specific bundles or languages. Test every transition with a real account from each role before go-live.

Drafts and published revisions

A moderated node keeps a published revision and a separate latest draft revision, so editors can change content without changing what visitors see. This is the basis for review before publication. Confirm how your version handles translations, revision deletion and the default revision after a rollback, because these behaviors affect what appears on the live site. Plan a revision retention policy so review history does not grow without limit.

Moderated content overview

The moderated content view lists items by state, author and workflow, which lets reviewers find content waiting for them. It is a view you can alter, so filters and columns can be adapted to your editorial teams. Check whether your version's default view covers every moderated entity type you use, and whether it respects access restrictions for large teams. Scale tests with realistic content volumes before relying on it for daily queues.

Workspaces for grouped changes

Workspaces let a team build several content and configuration changes in a separate staging area, then publish them together as one deployment. This is useful for campaigns, seasonal launches and site-wide redesigns. Confirm which entity types and configuration can be included in a workspace in your version, and how conflicts are handled when two workspaces edit the same item. Note that workspaces are a Drupal core feature that is still maturing, so test publishing order and rollback on a copy of production.

Roles and permissions

Moderation and workspace access are controlled by permissions per workflow, transition and workspace, which must be combined with your content-type and field access. A role that can edit content but not publish needs a deliberate set of transition grants. Document which role can create workspaces, push them live and delete them, because those actions affect many items at once. Review the permission matrix with your security and editorial leads before launch.

Which combination fits your editorial model

A single site with one review queue usually needs only the core Workflows and Content Moderation modules. Content Moderation attaches a workflow to content types, so each piece of content moves through states such as draft, in review and published, and only users with the right transition permissions can move it forward. This is the simplest model and the one with the fewest moving parts to maintain through upgrades.

Editorial states: List the states your team needs, such as draft, needs review, approved and published, and keep the number small enough that editors can remember what each one means.
Transition permissions: Decide which roles may create drafts, request review, approve and publish, since these map directly to Drupal permissions.
Content types in scope: Decide which content types go through the workflow and which publish directly, because the workflow applies per content type.
Notifications: Decide how reviewers learn that work is waiting, since core Content Moderation does not decide that for you.
Scheduled changes: Decide whether editors need timed publishing, which usually means a separate contributed module such as Scheduler.

Confirm with your editorial lead that a single queue is enough before you add anything. Ask your implementation partner how the workflow will be tested for each transition role.

Configuration decisions: states, transitions, roles and content types

This table lists the Drupal configuration decisions that change how Content Moderation and Workspaces are built, with the options for each and when they fit. Read it before workshops with editors and security reviewers, because several choices, such as whether Workspaces is needed at all, affect data model and testing effort more than the workflow diagram does.

Decision	Options	Trade-off and when to choose it
Number of moderation states	Two states (draft, published) or a fuller chain such as draft, in review, approved, published	Each added state needs roles, transitions and tests. Add a review state only when a second person must sign off before publication.
Transitions per role	Author-only submit, reviewer approve and publish, or a single publisher role	Separating submit from publish gives a clear audit trail but more role assignments to maintain. A single publisher role suits small teams with few reviewers.
Which content types are moderated	All content types, or only public-facing types such as articles and landing pages	Moderating everything adds review steps to low-risk content like internal lists. Limit moderation to content that carries legal, brand or regulatory exposure.
Translations and revisions	One workflow state per entity across languages, or separate states per translation	Per-translation states suit sites where each language has its own reviewers. Shared states are simpler but can publish a translation that is out of date with its source.
Use of Workspaces	Not needed, or enabled for site-wide staging of campaigns, migrations or redesigns	Workspaces stages changes across many entities together and adds complexity to content, menus and aliases. Enable it only when coordinated releases are a real requirement, and confirm compatibility with each contributed module in use.
Permission model	Core permissions only, or combined with a section-based module such as Workbench Access	Core permissions cannot restrict editors by department. Add a section-based module only when large teams must be limited to their own content.
Scheduled publishing	Manual publishing only, or scheduled publish dates through a contributed module	Scheduled publishing interacts with moderation states and cron timing. Decide early which state a scheduled item sits in before it goes live.

How roles and permissions carry the workflow

Moderation in Drupal is enforced by permissions, not by the workflow diagram alone. Content Moderation lets a workflow define states such as draft, review and published, and transitions between them, but each transition is granted to roles per content type. The role design therefore decides who can publish, who can only move content to a review state, and who can create and switch workspaces with the Workspaces module. Before building the workflow, map each role to the exact transitions it may use, and write down which roles should have no publishing rights at all. Confirm the permission names and the workspace permissions in the documentation for your Drupal version, since the labels and the way they group under each content type have changed across releases.

The failure that surfaces most often is an editor who can still edit live content they should not touch. This usually happens because a role was granted the general edit permission for a content type, or an administrative permission, and nobody checked how that interacts with the moderated states. An editor may be able to change a published revision directly, or to create a new draft over a live node, bypassing the review step the team believes is in place. Check this against the content types and roles you actually run, not against the permission list in the abstract. Confirm what each role can do on the published revision and on a new forward draft, and remember that workspace permissions add a second path to the same content.

Permissions should be tested with real accounts, one per role, on a staging copy that mirrors production configuration. Log in as each role, attempt every transition and every edit route, and record which actions succeed, fail or show the wrong state. Include users who hold more than one role, because the effective access is the combination. Repeat the test after each change to roles, workflows or contributed modules that alter access, and after each Drupal core update. Written test results become the evidence your reviewers and auditors can follow, and they catch the gaps that a review of configuration files alone tends to miss.

How an editorial workflow build moves from design to launch

The sequence below takes an editorial process from written states and roles to a tested, trained and handed-over Drupal workflow, with each step producing a named artifact the next step depends on. It is designed to keep permission decisions and content-state changes visible before anything goes live.

Confirm the editorial process and states
Map how content moves today, from draft and legal review through approval, scheduled release and archive, and agree the states that will exist in Drupal along with who can move content between them. Editors, the content owner, legal or compliance reviewers and the Drupal lead attend this session together. The output is an approved state model: a short document listing each state, its meaning, the allowed transitions and the role that triggers each one. The step is done when the business owner signs the model and no open questions remain about exceptions such as urgent corrections.
Map roles and permissions
Translate the approved state model into Drupal roles and a permission matrix. Each role is listed against each content type, each transition and each operation such as creating drafts, viewing unpublished revisions, or publishing, so that the rules are reviewed before they are configured. Access that must be limited to a department or section is noted now, because it may call for a separate module. The output is a permission matrix signed off by the content owner. The step is done when every role has a documented reason for each permission it holds.
Configure workflows on the content types
Build the workflow in the Drupal administration interface using the core Workflows and Content Moderation modules, then attach it to the content types, and where needed the media or other entity types, that the state model covers. Configure the states, transitions and the permissions that map to the matrix, and confirm that content types outside the workflow are not left in an ambiguous state. Changes are made in a development environment and exported to configuration, so the same workflow can be reviewed and deployed. The output is a version-controlled workflow configuration. The step is done when a sample node of each type moves through every transition.
Add Workspaces if staging is needed
Decide whether the business needs to stage site-wide changes, such as a redesigned section, a campaign with linked pages and menus, or a batch of coordinated edits, before they go live together. If it does, enable the core Workspaces module and confirm how it interacts with Content Moderation for each content type, since the two features solve different problems and must be tested together. Confirm the Drupal version and module behavior against current documentation before you commit. The output is a short note on which content is staged in a workspace, who can create and deploy them, and how conflicts are handled. The step is done when a test workspace can be built, previewed and deployed without changing live content unexpectedly.
Migrate or clean up existing content states
Inspect content already on the site or in the source system and map each existing status, such as an old published flag or a custom field, to a state in the new model. Content that does not fit is listed for editorial decision rather than guessed at. Migration scripts or a content audit run against a copy of the database, and the results are compared with the source counts and sampled by an editor. The output is a state mapping table and a migration report. The step is done when every legacy item has a target state and the editors confirm the sample.
Test transitions with each role
Write test scripts that follow each role through its permitted and forbidden actions, covering normal approval, rejection back to draft, scheduled publishing, unpublishing and the handling of content in a workspace. Testers sign in as each role on a staging environment that mirrors production configuration, record the result of each case and file defects against the configuration or the permission matrix. Retests cover every fixed defect. The output is a signed test report with the scripts attached. The step is done when every script passes for every role and the content owner accepts the results.
Train editors and reviewers
Run role-based sessions so that authors, reviewers, publishers and administrators learn the steps that apply to them, using the actual staging site and the test scripts as the basis for exercises. Each session covers what the editor can see, what a state means and what to do when a transition is blocked. Training records are kept for each person. The output is an editor guide written in the organization's own terms, with screenshots taken from the built site and a named support contact. The step is done when each role completes a practice exercise without assistance from the project team.
Hand over and confirm ownership
Deploy the workflow, workspace and permission configuration to production through the agreed release process and confirm the result with a short live check. Hand over the configuration repository, the state model, the permission matrix, the test report, the migration report and the editor guide, and agree who maintains the roles when staff change. The handover records who owns future changes to states and roles, since a Drupal upgrade or a new content type can alter how workflows behave. The output is a handover pack and a confirmed owner for each artifact. The step is done when the business owner and the Drupal operations team both sign the handover.

What drives effort and cost in an editorial workflow project

This table lists the main drivers that change the size of a Drupal editorial workflow project, with a column for how to keep each one manageable. Read it before scoping, because most of the effort comes from the number of states, roles, translations and integrations rather than from the modules themselves. The main takeaway is that fewer workflow states and a tested permission matrix usually reduce both build and support effort.

Driver	Why it changes effort or cost	How to keep it down
Content types and translations	Each moderated content type and each translated language adds states, revisions, forms and test cases to verify.	Moderate only the content types that need review, and confirm with translators whether each language needs its own review step.
Roles and exceptions	Every role needs a permission set across each transition, and one-off exceptions multiply the matrix that must be tested.	Start with a small set of editor, reviewer and publisher roles, and add exceptions only when a documented business need exists.
Number of workflow states	Each extra state adds transitions, permission combinations and editor questions about which state applies.	Keep to the states the business uses today, such as draft, review and published, and add others after launch.
Workspaces and section controls	Workspaces for site-wide staging and section-based restrictions such as Workbench Access add configuration, testing and governance work.	Confirm whether staged releases are required, and choose one section control model rather than combining several by default.
Existing content in inconsistent states	Legacy nodes without a moderation state, or with conflicting published and draft revisions, need cleanup and mapping before rollout.	Audit current content early, define a default state for legacy items and script the cleanup where practical.
Integrations that publish or read moderated content	Feeds, syndication, search indexing and external APIs must respect which revision is current, which adds test scenarios and possible rework.	List each integration and confirm which moderation state it reads or writes before the build starts.
Editor training and change management	Editors need to learn states, transitions and staging previews, and training effort grows with the number of roles and exceptions.	Keep the workflow consistent across content types, document it in short role guides and plan a pilot group before wide rollout.
Testing and permission verification	Each role and transition combination needs verification, and missing tests usually surface as access defects after launch.	Maintain a written permission matrix, automate checks where feasible and ask the partner to include it in the fixed-scope deliverables.

Moving existing content into a moderated model

The first decision when turning on Content Moderation for an existing site is what happens to content that already exists. Enabling the module on a content type does not give existing nodes a moderation state automatically in a way you can rely on without checking. Each node needs to land in a workflow state (for example, Published or Draft) that matches what editors believe is live, and you should confirm that by sampling content types before any editor starts working in the new model. Pay particular attention to forward revisions: a node may already have a newer draft revision sitting beside its published default revision, and that draft will behave differently once moderation controls which revision is the default. Run a report of nodes with pending forward revisions, decide whether each one is kept, published or discarded, and assign an owner to that decision before go-live.

If the site still runs Drupal 7, the content cannot be moderated in place, because Drupal 6 and 7 sites cannot simply be updated to Drupal 10 or later. The content has to be migrated into a new Drupal site using the core Migrate, Migrate Drupal and Migrate Drupal UI modules or Drush, and themes must be rebuilt. Moderation is then configured on the new site, and the migrated nodes are checked against the same state and revision questions. Drupal 7 security support ended on January 5, 2025, according to Drupal.org. Where a migration cannot happen yet, the Drupal Association's Extended Security Support Provider Program lists certified vendors, including HeroDevs and Tag1 Consulting, who support sites that cannot migrate yet. Confirm their current terms directly with each provider, since the program's coverage is their commitment, not ours.

Before you enable moderation, record the editorial roles that will own each state transition, because existing content often has authors who no longer hold the role that will be needed to publish it. Check that the permissions for transitioning content are granted to the right roles on the migrated or upgraded site, and test one representative node per content type through the full path from draft to published. Plan a short freeze or a dated cut-over so that editors do not create new revisions while the state of existing content is being reconciled. Ask your implementation partner to document the cut-over steps and the reconciliation report as deliverables in the written scope, so the handover does not depend on one person's memory.

How editorial workflows connect to the rest of the platform

Content Moderation and Workspaces decide who can publish and what a draft looks like, but the published state is read by identity, search, translation, caching and syndication. Each of these connections needs a decision about draft versus published content before the workflow goes live.

Editor identity and SSO

Editor accounts decide who can move content through review, so their sign-in path matters as much as the role model. The contributed SAML Authentication module (samlauth) lets Drupal act as a SAML service provider, and the OpenID Connect module creates accounts on first sign-in. Check that the chosen module supports your Drupal version, confirm how group claims map to Drupal roles, and decide whether accounts are created on first sign-in or pre-provisioned.

Scheduler and moderated states

The contributed Scheduler module publishes and unpublishes content on dates that editors set. Its interaction with Content Moderation needs a rule: a scheduled transition should only run from a state your workflow allows, and the editorial team should know whether a scheduled item can bypass review. Confirm the module's compatibility with your Drupal version and test time zone handling with editors in each region.

Search indexing of drafts

A search index that includes unpublished revisions can expose draft text to the public or to users without view access. Configure Search API so that only published, accessible content is indexed for public search, and decide whether editors get a separate index or a draft-aware search page. Re-indexing must run when a moderated state changes, so confirm how your queue and cron run in your hosting setup.

Translation and syndication

A translated or syndicated copy can go live while the source is still in review, which breaks the approval record. Decide whether translations follow the source workflow, whether a source update resets translation states, and whether syndicated content from Entity Share carries moderation states across sites. Test each path with a draft, a published revision and a forward revision before launch.

Caching and CDN purging

A reverse proxy or CDN that caches pages will keep serving the previous published version after an approval unless purge events fire on the right transitions. Confirm which cache tags your CDN module supports, verify that publishing from a workspace or moderated state triggers purges, and set a rule for how long stale content may remain visible. Test purging against the real CDN configuration, not a local cache.

Questions teams ask before building editorial workflows

What drives the cost of building an editorial workflow in Drupal?

The main cost driver is how many distinct review paths the content needs, not the number of modules installed. Each content type that follows its own path, each moderation state, each transition with side effects such as notifications or field changes, and each role that needs a different set of permissions adds design, configuration and testing work. Content Moderation and Workflows are core modules, so the license cost is zero, but the work of defining states and transitions is paid labor. Ask any quote to break out discovery, configuration, custom code (if any), testing and handover as separate lines, and to say which items are one-time and which recur through maintenance.

How long does a Content Moderation and Workspaces project usually take?

Duration depends on scope more than on the modules themselves. A single content type with one approval path and a small set of roles is a much smaller piece of work than several content types, multiple languages, scheduled releases and site-wide staging with Workspaces. The points that usually extend the timeline are unresolved decisions about who approves what, content that needs to move between sites, and permission models that must match an existing identity system. Because most DeployOpen engagements are fixed-scope, the timeline is agreed in writing before work starts, and any estimate should follow from that written scope.

What must our team provide before the build starts?

Four inputs decide most of the early work:

Process owners who can sign off each state, transition and exception path.
A role list that names who creates, edits, reviews, publishes and administers content, including any cross-department reviewers.
A content inventory listing content types, their volume, owners and the pages or features that depend on them.
Test accounts for every role, on a non-production environment, so each permission can be checked before launch.

Without these, the team tends to discover approval gaps during user acceptance testing, which is the most expensive point to change a workflow.

Can our internal Drupal team configure Content Moderation alone?

Often yes, for a bounded workflow. Creating a moderation workflow, assigning content types and defining roles is configuration through the admin interface, and a team with Drupal administration experience can do this with the core documentation. The harder parts are workflows that trigger custom logic, permission models that must respect content ownership or sections, and Workspaces combined with multilingual or scheduled content. Your team should check whether it can test those cases properly, keep the configuration in version control and document the results for future editors. A partner is most useful for the design decisions and the test plan, which an internal team can then run.

What breaks most often in editorial workflows after launch?

The most common failures come from changes made after go-live without a review of the permission model. New content types added without a moderation workflow, roles granted edit access that bypasses review, and Workspaces used in combination with features that do not behave the same way across all workspaces are typical examples. Teams should check that every new content type is assigned to a workflow, review role changes against the documented matrix, and run a short test pass after each Drupal core or contributed module update. Security updates for Drupal core are released on a scheduled cadence, so the test pass should fit into the regular update routine.

How do Workspaces and Content Moderation affect site security and audit evidence?

Both modules control who can change published content, which makes the role and permission matrix part of your access control evidence. Record which roles can move content through each state, who can publish, and who can create or deploy a workspace. Keep the exported configuration under version control so changes are traceable. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications; independent auditors and certification bodies make that judgment. Confirm your own control requirements with your compliance team before the design is fixed.

When is it worth bringing in a partner for editorial workflows?

A partner is worth considering when the workflow has to match a real approval policy with several departments, when Workspaces must be combined with multilingual content, scheduling or integrations, or when the team lacks time to write and run a permission test plan. A partner can also help when an existing Drupal 7 site is being migrated and its old workflow logic has to be redesigned rather than copied. Ask for a written scope that lists the states, roles, content types, integrations and test cases, and compare quotes on that basis rather than on headline effort alone.

Official Drupal documentation for this module

Before you design any moderation states or workspace structure, confirm which Drupal version and PHP version the project will run on, because the behavior of Content Moderation and Workspaces depends on both. The Drupal core release schedule shows which major version is current, when the next one is scheduled and when the version you pick will reach end of life. Drupal 11 is the current major version at the time of writing, Drupal 12 is scheduled for the week of December 7, 2026, and Drupal 10 reaches end of life on December 9, 2026. A workflow built on a version that is close to end of life will need to be rebuilt sooner than the editorial team expects, so put that date into the project plan from day one.

Next, check the Drupal.org system requirements and the PHP requirements for your target version. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later. Confirm that the hosting platform, database and web server you have chosen are supported for that version before the workflow design is locked, since a server constraint can change which version is practical. Ask your hosting team to confirm the exact PHP runtime they will provide in each environment, not only in production.

Finally, confirm the Drupal.org project pages for Content Moderation, Workflows and Workspaces against the version you select, and read the issue queues for any open problems affecting your planned setup, such as custom entity types or multilingual content. Record the module versions in your build plan and in the configuration you export, so that an upgrade reviewer can see which documentation the design followed. Treat any behavior you cannot find in the official documentation as an assumption to test in a staging environment, not as a fact to build on.

How DeployOpen scopes and delivers editorial workflow builds

DeployOpen plans, builds, documents and supports editorial workflows on Drupal inside infrastructure you control. Engagements start with a written, fixed scope that defines which workflow states, roles and staging behavior are delivered, so editors, reviewers and administrators know what the site will do before build work begins.

How we scope

Map your current publishing steps, approvers and content types before choosing workflow states and transitions.
Define which roles can create, review, publish and archive each content type, and which ones need Workspaces access.
Agree in writing which content types, languages and sites are in the Content Moderation scope and which stay outside it.

How we build

Configure the core Workflows and Content Moderation modules with states and transitions that match the approved process.
Set up Workspaces for site-wide staging and document where Workspaces is and is not appropriate for your content model.
Test each role and permission combination with scripted editorial scenarios, including publishing, reverting and conflicting edits.

How we hand over

Deliver a written permissions matrix and workflow diagram that editors and administrators can review and approve.
Document the configuration, the custom code and the settings that must be exported under configuration management.
Walk your editors and site administrators through the review process, the staging flow and the known limits of each.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after launch, separate from the fixed-scope build.
Plan Drupal core and contributed module updates against the release schedule so workflow configuration is retested each cycle.
Ask for a written quote that lists scope items, deliverables, dependencies and any recurring retainer terms before work starts.

Drupal editorial workflows with Content Moderation and Workspaces