Drupal Workbench Access for section-based editorial permissions

Drupal Workbench Access for section-based editorial permissions: when large teams need it

A large editorial team on one Drupal site often hits the same problem: the marketing department should edit only its own pages, the regional offices should edit only their pages, and nobody should be able to change the homepage except the central team. Core content types and roles can separate some of this, but they do not follow an organizational tree. Workbench Access is the contributed module built for that case. According to its Drupal.org project page, it creates editorial access controls based on hierarchies and supports structures created by other Drupal modules, so the section tree your organization already uses can drive who edits what. The current 2.0.5 release supports Drupal 9, 10 and 11, which you should confirm against your target core version before you commit to a design.

Teams usually implement Workbench Access when the number of sections, editors and handoffs grows beyond what content types and roles can express cleanly. If access depends mainly on what kind of content something is, a content type split is simpler. If access depends on who owns a section of the site, Workbench Access fits better. Before building, decide where the section hierarchy lives (a taxonomy vocabulary or menu structure), who maintains it, and how a new department is added. Decide also whether editors need to see other sections in lists and search, since Workbench Access controls editing and does not replace a separate content visibility model. A community or intranet with partner members may be a better fit for the Group module, so compare those options at the start.

Workbench Access is most useful when paired with Content Moderation. Section access determines which editors can touch a page, while the moderation workflow determines who can approve it and publish it. Map each section to its reviewers, confirm that the moderation states and transitions match the approval chain, and test a draft from every role before launch. Plan for hierarchy changes such as reorganizations or retired sections, because moving a section can change access for many editors at once. Ask any implementation partner to show how the access tree is reviewed, how changes are logged and how the configuration is kept in version control, since these decisions affect the cost of running the site after go-live.

What Workbench Access does on a Drupal site

Workbench Access works by mapping editors to sections of a site and then limiting what they can edit inside those sections. The cards below cover the parts of the module that shape a section-based permission model, and the points to confirm before you commit to a hierarchy.

Section hierarchies

Workbench Access builds editorial access on a hierarchy of sections, so a parent section can contain departments, regions or teams beneath it. Decide the depth and naming of this tree before any content is migrated, because moving sections later changes who can reach which content. Confirm how the 2.0.5 release handles nested sections against your planned structure.

Assigning users to sections

Editors are assigned to one or more sections, and that assignment defines the content they may create or edit within those sections. Plan which roles can change assignments, since those people become the administrators of your editorial boundaries. Test a user who belongs to two sections to confirm the access they receive matches your intent.

Assigning content to sections

Content is associated with a section so that access rules can apply to individual nodes as well as to whole branches. Decide who may move content between sections, because a change of section can remove an editor's access to an item they just worked on. Include a review of how existing content gets its section during migration.

Structures from taxonomy and menus

The module supports section structures created by other Drupal modules, such as taxonomy vocabularies and menus, so you do not have to maintain a separate tree by hand. Choose the source that matches how your organization already names its departments, since the source becomes the record of truth. Confirm the supported source types and their configuration in the module documentation for your release.

Interaction with editorial workflow

Section permissions sit alongside Content Moderation, so an editor's section access and their workflow transitions both limit what they can publish. Map each moderation state to the roles that may move content into it, and test that a reviewer outside the section cannot approve it. Verify the combined behavior on your own configuration rather than assuming it from either module alone.

Compatibility and upgrade checks

Workbench Access 2.0.5 is listed as supporting Drupal 9, 10 and 11, which matters if your site is planned to move toward Drupal 12. Check the module's compatibility before each core upgrade, and include the section configuration in your upgrade test plan. Ask whether any other contributed modules in your stack affect section access.

Taxonomy or menus: which hierarchy should drive section access?

A taxonomy vocabulary gives each section a term with a parent, so the hierarchy lives in the data model rather than in the site's navigation. Workbench Access can use a hierarchy like this as its section tree, and editors are granted rights to specific terms. The structure is independent of how pages are displayed, which makes it a good fit when sections are an organizational concept that several sites or views share.

Maintainer: Usually a site builder or content governance owner edits the vocabulary, and the list is controlled by whoever holds the taxonomy permissions.
Reorganization: Moving a department means moving a term under a new parent, which changes the tree without touching any page.
URLs and aliases: Term pages and their aliases are separate from the section assignment, so a renamed term can keep its old URL only if the alias is set up deliberately.
Assigned content: Content tagged with a renamed or moved term keeps its reference, so the editorial scope follows the term, but any field that was used for display may need an update.
Dependencies: Confirm with your Workbench Access configuration that the vocabulary field on content is the one the section logic reads.

Before committing to this model, check how your current governance team plans to rename terms and whether they have a process for approving changes to the vocabulary.

Configuration decisions that shape the section model

This table compares the six configuration decisions that determine how Workbench Access sections are built and who can edit what. Read each row as a decision point: the options, when each fits, and the risk of choosing without testing it. Most of the rework on section-based projects traces back to the first three rows, so settle them before building editor roles.

Decision	Options and when each fits	Risk of getting it wrong
Section source	Taxonomy suits sections that exist as a stable vocabulary, such as departments or regions. Menu suits sites where the navigation tree already mirrors the organization. Choose the source that the content team will maintain without developer help.	Switching sources later means remapping every access assignment. A menu-based model can change when someone reorganizes navigation and silently alter editor access.
Hierarchy depth	Shallow hierarchies (one or two levels) suit a few departments with clear ownership. Deeper trees suit large organizations with divisions, teams and sub-sections. Confirm that the chosen depth matches how the organization assigns responsibility.	Deep trees make inheritance hard to reason about and slow reviews of who can edit what. Flat structures can force unrelated teams to share a section and its editors.
Multiple sections per content item	Single assignment keeps ownership clear and audits simple. Multiple assignment suits shared content such as a policy that several departments publish. Decide who owns the item when sections disagree.	Allowing multiple sections without an owner rule can let editors in one section change content they do not own. Restricting to one section can force duplicate content.
Who assigns sections to editors	A central administrator role keeps control in one team and suits regulated or small estates. Delegated section managers suit large organizations where each department onboards its own staff. Confirm the approval step in writing.	Unrestricted delegation can grant access beyond a department's remit. Central-only assignment can create a backlog that pushes teams toward shared accounts.
Top-level content creation by section editors	Allow it only when section editors publish site-wide pages such as home or campaign pages. Deny it for most estates, so section editors work only within their branch of the hierarchy.	Granting it by default lets one department publish across the whole site. Denying it without a route for shared pages can push editors to request exceptions outside the process.
Content Moderation states mapped to section roles	Separate draft and publish roles per section suit review-heavy teams with legal or brand approval. A single editor role with a central publisher suits smaller teams. Map each transition to a role and test every path.	Editors who can publish without review bypass the workflow. Unmapped states can leave content stuck in review with no section role able to move it forward.

Implementation sequence and the output of each step

The sequence moves from an audit of how editors actually work to a tested, cut-over permission model, with a named output at each stage so that content owners, security and the Drupal team can sign off before editors are restricted. It is built so that section access and review workflow are designed together rather than bolted on after launch.

Audit current editorial teams and content ownership
DeployOpen interviews content owners, department leads and editors, and reviews the current roles, content types and any ad hoc ownership rules on the existing site. The team records who creates, edits, reviews and publishes each content type, and which content has no clear owner. The output is a current-state inventory that shows where editors today can touch content outside their area and where approvals happen outside the site. The step is done when the client's content owners confirm the inventory matches how the work really flows.
Design the section hierarchy and approved section map
The team decides whether sections come from a taxonomy, a menu or another structure the site already maintains, and how deep the hierarchy goes. They decide who owns each section, whether parent sections grant access to children, and how shared content is handled. The output is an approved section map signed off by the business owners, with each section assigned a named owner. The step is done when every section has an owner and the open questions about shared content are written down with a decision.
Configure Workbench Access on a development site
Engineers install Workbench Access and connect it to the chosen hierarchy source, then configure the sections, the section-to-node relationships and the scheme that controls how editors are assigned. Configuration is kept in version control so it can be reviewed and reproduced. The output is a development build where sections can be assigned and where a test editor sees only their own sections in the content listing. The step is done when the configuration exports cleanly and a sample section assignment behaves as the map specifies.
Map roles and permissions to sections
The team translates the audit and section map into a permission matrix that lists each role, the operations it allows (create, edit, review, publish, delete), and the sections where it applies. They check that core permissions, Workbench Access grants and any custom code do not conflict, and they document any role that needs cross-section access with a stated reason. The output is a permission matrix reviewed by the client's security or governance lead. The step is done when every role in the matrix has an owner who approved it.
Integrate section access with Content Moderation
Engineers attach the editorial workflow states to the section model so that a reviewer can approve only content in their sections, and so that moving content between sections triggers the right review. They confirm which transitions editors, reviewers and publishers can perform and whether a section owner must approve publication. The output is a workflow test sheet listing each state transition and the role and section that can perform it. The step is done when every transition in the sheet has been tested for both an allowed and a denied case.
Assign existing content to sections
Because the new model only restricts content that has a section, existing nodes must be assigned before editors are restricted. The team uses a scripted or batched assignment driven by the audit, with a report of content that has no obvious owner and must be decided by a named person. The output is an assignment report showing counts per section, the exceptions list and the owner who resolved each exception. The step is done when no published node is left unassigned without a recorded decision.
Test with test accounts and record results
The team creates one test account per role and per section, and runs scripted checks for listing, editing, moderation and publishing across the permission matrix. Failures are logged with the account, the action and the expected result, then fixed and retested. The output is a test log that shows each case, its result and the retest date. The step is done when the log has no open failures and the business owners accept the results in writing.
Cut over and confirm access with real editors
The team schedules the switch to the production permission model, communicates the change to editors and provides a short guide on their sections and the new review path. After cutover, the team checks a sample of editors' access on production and watches for support requests about missing content. The output is a signed cutover record that names the configuration version deployed and the first post-cutover review. The step is done when the record is filed and open access questions have an owner.

How Workbench Access and Content Moderation work together

Large editorial teams usually combine section access with review and approval so that each step stays inside the same boundary. A section editor drafts content only within the departments or sections they belong to, a reviewer approves that content within the same area, and the right to publish is held separately from both. Workbench Access supplies the section boundary through its hierarchy, while Content Moderation supplies the states and transitions that a piece of content moves through. Neither module decides the full workflow alone, so the design has to be checked as a combination.

In a test environment, start by listing every transition in your moderation workflow, such as create draft, request review, approve and publish, and record which roles can perform each one. Then confirm, with a test account in each role, whether a section editor can move content from draft to review only for sections they belong to, and whether a reviewer can see and approve content from a section they are not assigned to. Check how a node that is moved to another section behaves while it is in a review state, and whether the previous section's reviewers still hold access to it. Also confirm which permissions control the ability to publish, because a role that can approve and publish in one step removes the separation you intended. Confirm these behaviors against the versions you run, since the Workbench Access documentation and your own tests are the reliable sources for how the two modules interact.

What drives effort and cost on a section-based permission model

This table lists the factors that most change the effort of a Workbench Access project, how each one raises cost, how to keep it down, and what to request in a written quote. Read it before scoping, because the same section model can be a small configuration task or a large migration depending on these inputs.

Driver	Why it changes effort	How to keep it down, and what to ask for in a quote
Number of sections and depth	Each section is a node in the access hierarchy that needs editor assignments, and deeper trees multiply the rules that inherit or override access.	Model only the levels editors truly manage. Ask the quote to state the section count, maximum depth and which levels are assigned to editors.
Existing content needing reassignment	Every node that predates the model must be mapped to a section, often by rule or by hand, and the mapping must be tested against real editor accounts.	Ask whether content can be assigned by rule from a field or menu parent. Quote the content volume, the assignment method and who reviews exceptions.
Distinct editorial roles	Each role combines Workbench Access sections with content types, text formats and moderation transitions, so the permission matrix grows with every role.	Consolidate roles to a short list before build. Ask for the role matrix as a deliverable and a count of roles covered by testing.
Moderation workflows in use	Content Moderation transitions must be granted per section and per role, and each workflow adds states that editors and reviewers need to test.	Limit workflows to the states the business uses. Ask the quote to list each workflow, the transitions it grants and the sections it applies to.
Integrations that read or write content outside the UI	Feeds, APIs, migrations or syndication jobs can bypass the editing form, so section rules must also be enforced or deliberately excluded for those accounts.	Inventory every integration user and token. Ask the quote to show how each service account is assigned, tested and documented.
Quality of the current taxonomy or menu	Workbench Access builds its hierarchy from existing structures, so inconsistent terms, duplicate names or orphaned menu items force cleanup before the model works.	Audit the vocabulary or menu before scoping. Ask whether cleanup is in the quote or the client's responsibility, and who signs off the final structure.
Testing across accounts	Each section and role pair needs positive and negative checks, and failures often appear only after moderation or cache changes.	Ask for a named test matrix, the environments used and the acceptance evidence expected before go-live.

How Workbench Access connects to the rest of the platform

How does Workbench Access sign-in work with an existing identity provider?

Workbench Access does not authenticate users itself. It relies on the Drupal account, so the identity provider has to create or match accounts first, and the section assignments are then applied to those accounts. The usual route is the SAML Authentication module (samlauth) or the OpenID Connect module, which both create accounts on first sign-in. Confirm which attributes your identity provider sends for department or group, whether they are stable identifiers, and who owns the mapping. If section membership is changed only in the identity provider, decide how and when Drupal picks up the change, because a user who signs in once and never returns may keep old section access until the mapping runs again.

Does Content Moderation still apply to content inside a section?

Yes, the two controls work at different layers. Workbench Access decides which sections an editor can see and edit, and Content Moderation decides which transitions, such as draft to review to published, that user may perform on content they can reach. Test each combination of role and section in a staging site, including who may publish, who may only request review, and whether a reviewer in one section can approve content filed under another. Confirm the workflow design with the content owners before you configure permissions, since a role that works in one section can unintentionally grant publishing rights in another.

Can Group and Workbench Access be used together for communities?

They can overlap, but they solve different problems. Group gives members of a community their own content and permissions inside one site, while Workbench Access organizes editorial access around a hierarchy such as departments or regions. Decide early which model owns each piece of content, because two permission systems that both grant access to the same node can produce results that are hard to explain to an auditor. Confirm with your team whether intranet communities need section-level editing at all, and document the rule that resolves conflicts before the first content is migrated.

Will search results respect section visibility?

Not automatically. A search index built with Search API stores content that the indexing user is allowed to see, so section restrictions must be carried into the index as data, usually through an indexed field for the section or an access check at query time. Confirm which search backend you use, whether it can filter by a section field, and how quickly the index updates when an editor moves content between sections. Test with a user from each section and check that no snippet, facet count or suggestion exposes content from another section.

How do feeds and migrations assign content to the correct section?

Imports and migrations write nodes directly, so they bypass the editing screens where section rules are normally applied. Each source record needs a section value that maps to a Workbench Access section, and any record without a valid section should be held back rather than published into a default area. Confirm the mapping table with the business owners of each source system, and run the import under an account whose section access you have tested. Plan a reconciliation step after each run that counts records per section, because a silent mapping error can place content where the wrong team can edit it.

What happens when external systems create nodes through an API?

A REST or JSON:API client that creates content runs as the account it authenticates with, so that account's section permissions decide what it may create. Create a dedicated integration account per source system with access limited to its sections, and confirm whether your chosen module and Drupal version handle section assignment on create and update requests. Document who owns each integration account, how its credentials are rotated, and what happens when a source system sends a section the account cannot write to. These checks are easy to skip during build and difficult to explain once content is live.

What should be confirmed before choosing an integration approach?

Start with an inventory: the identity provider and its attributes, every content source, the search backend, and any workflow or community features. For each one, confirm the Drupal version and module versions you plan to run, since Workbench Access 2.0.5 supports Drupal 9, 10 and 11, and the samlauth module's latest stable release supports Drupal 10.3 and later and Drupal 11. Ask your partner or internal team for a written test plan that covers each integration point with a user from every section, and ask what recurs after launch, such as module updates, attribute changes and integration account reviews.

How DeployOpen scopes and delivers Workbench Access

Workbench Access work starts with a written scope, because the permission model is hard to change once editors depend on it. DeployOpen agrees the scope, deliverables and timeline in writing before any configuration begins. For this topic, the two core deliverables are a section map and a permission matrix. The section map lists every section, department or menu branch that editors can be restricted to, and records which taxonomy vocabulary or menu hierarchy holds it. The permission matrix records which roles can create, edit, review and publish content in each section, and how those roles combine with Content Moderation transitions. Agreeing both documents before build turns a vague request for department-level access into something a client can approve line by line.

Configuration and testing happen in the client's own environment, on their Drupal codebase and their hosting, with no data leaving their infrastructure. Build follows the agreed section map and matrix: sections are created as Workbench Access hierarchy entries, roles are mapped to sections, and Content Moderation states are assigned per section. Testing then covers each role against representative content, including edge cases such as content that belongs to two sections, bulk operations and users who hold more than one role. Results are recorded against the permission matrix, so any gap is traceable to a specific row. Where a control depends on a module version, the team confirms compatibility with the supported Drupal version before release. Handover includes documentation of the hierarchy, the matrix, the test results and the steps to add a new section.

After handover, the client can keep the work current through an optional retainer. Retainers can cover ongoing support, module updates, and checks against the permission matrix when a Drupal core or contributed module release changes behavior. Ask any partner for the scope of a retainer in writing, including response expectations and which upgrades are included. Your own team should also confirm which Drupal version the site runs and when its support ends, since that date determines when permission logic must be retested. DeployOpen does not publish a price list, so cost follows from the agreed scope, with the section count, number of roles and integration with existing workflows as the main drivers.

Drupal Workbench Access for section-based editorial permissions