When a Drupal Group module implementation fits an intranet or community
When one Drupal site must serve several departments, member groups or partners, each needing its own content and its own rules for who can edit or view it, the Group module is the contributed tool to evaluate first. Group adds a container entity, a group, to Drupal so that content, memberships and roles can be scoped to that container instead of to the whole site. Teams usually choose it over separate sites when they want one login, one search index, one theme and one maintenance routine, while still letting a regional office, a project team or a partner organization manage its own space. Separate sites remain the better fit when each unit needs a different codebase, hosting boundary or data residency rule. Before any build starts, the first two decisions are which entities become groups and who may create them, and whether membership is open, approval-based or invitation-only. Those choices shape every later decision about roles, content types and search.
Group is contributed, not part of Drupal core, so the release you install must match the Drupal core version in your environment. Check the project page on Drupal.org for the branch that supports your core major version and confirm which Drupal core versions and PHP requirements that branch declares before you pick a target. Drupal's own PHP requirements page is the reference for the runtime your hosts need. Ask the module maintainers or your implementation partner to document the branch, its supported core versions and its planned end of life, because a Group branch that no longer matches your core version will block your upgrade path. The same check applies to every contributed dependency you plan to use alongside Group, such as Gnode-style content add-ons or access helpers, so record each one in the scope document with its branch and version.
A second decision sits with the editorial owners: how much autonomy each group should have over content types, menus and moderation states. Group can scope content to a group, but it does not decide the workflow on its own, so teams must map which steps belong to group administrators and which remain with central publishers. Write these answers down as a permission matrix, covering group roles, global roles and the content types each role may create, edit or delete. Ask for a review of that matrix before the build, because permission errors in a multi-group site are discovered late and are expensive to correct. Confirm how the chosen Group branch interacts with your planned search, reporting and single sign-on components, since those integrations read the same access rules.
What the Group module does inside a Drupal site
The Group module wraps content, users and permissions into a container that behaves like a bounded workspace. The cards below cover the parts that shape a community or intranet build, and each one names a decision you will need to confirm against the project documentation before you commit to a design.
Group types as the first decision
A group type defines the kind of container you are creating, such as a department, a partner space or a project team. Each type carries its own fields, roles and the content plugins it can hold. Treat the type list as a data model review: adding a new type later means reviewing permissions, menus and reporting again. Confirm which group types the current release supports and whether you need one type per audience or one type with a field that separates them.
Group membership and its states
Membership connects a user account to a group and records which roles that user holds inside it. Users can join through an invitation, a direct add by a group administrator or, depending on configuration, a self-service request. Plan who is allowed to add members, how partners' users are onboarded, and how departures are handled, because membership records decide who can see group content. Verify the membership states and the join methods you rely on against the module's documentation.
Group-scoped roles and permissions
Group roles sit alongside site-wide roles and grant permissions only within a single group. A user can be an editor in one department and a reader in another without any change to the global role. The risk is in the global permissions you hand out: a broad site role can bypass group boundaries for the content types it covers. Map every role to a written permission matrix and test it with accounts from each group before launch.
Attaching content to a group
Content is associated with a group through group content plugins, which decide which entity types and bundles can belong to a group. Nodes, media and other entities may need different plugins, and content created outside a group form context may not be visible to group members. Decide which content types are group-owned and which stay site-wide, and confirm how existing content is assigned during any migration from a flat site structure.
Group visibility and access checks
Visibility settings determine whether a group is public, restricted to members or hidden, and they interact with node access and the entity access checks that Drupal runs on each request. Overlaps between group visibility and other access modules can produce results that no single configuration screen shows. Plan a test matrix that covers anonymous users, authenticated outsiders, members, and group administrators, and confirm the behavior on listing pages, search results and feeds.
Version support and upgrade planning
The module publishes branches for specific Drupal core versions, and the branch you choose sets the core versions you can run. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026, so a group structure built now will need a compatible module release for the next core. Ask the project page which branch supports which core version, and schedule the upgrade test before the branch you depend on stops receiving updates.
Which access model fits your departments, members and partners
This table compares four ways to separate content and editing in one Drupal estate: the Group module, core multisite, Domain Access and Workbench Access. Read each row as a question about what your teams must share and what they must keep apart, then check the fit against your governance model. The main takeaway is that Group handles membership-scoped access inside one site, while the other three separate by code, database or editorial section.
| Option | When it fits | What it shares or separates | Main trade-off |
|---|---|---|---|
| Group module alone | Departments, member communities or partners need their own pages, files and roles inside one public or intranet site | Shares one codebase, database, theme and configuration; separates content and permissions per group membership | Group roles and content access add query and permission complexity that grows with the number of groups and memberships |
| Core multisite | Sites must be fully independent with separate settings, modules or hosting boundaries | Shares codebase only; separates database, files, configuration and editors per site | Each site needs its own updates, backups and release coordination, which multiplies operational work |
| Domain Access | Several branded or regional sites need shared content with per-domain assignment on one installation | Shares codebase, database and most content; separates domain assignment, some configuration and editor scope per domain | Editorial rules and content assignment must be designed carefully, and it is not a substitute for membership-based access |
| Workbench Access | Editors should be limited to a department or section for editing and review within one site | Shares codebase, database and content; separates editing rights by section hierarchy from taxonomy or menus | Controls who edits, not who sees membership content, so it is often paired with Group or Content Moderation |
| Decision check | Confirm with your architects which boundary is a security requirement and which is an editing convenience | Ask whether partners must never see each other's content, and whether they need separate administrators | Confirm module versions and upgrade paths for each option against the Drupal release schedule before committing |
How group roles map to departments, members and partners
Department groups usually have long-lived ownership and map to the organization chart. Membership is most often granted by the department head or an HR-driven onboarding process, and revoked when someone changes role or leaves. Access is typically broad within the group but shallow outside it, so the group design should reflect who owns each content area and who may publish on the department's behalf.
- Owner role: A group owner or manager role that can add members and manage group content, assigned to a named accountable person rather than a shared mailbox.
- Editor and member roles: Separate roles for people who write and people who only read or comment, so publishing rights are granted deliberately.
- Approval path: Department heads approve additions, and the site administrator confirms that the approver is still in post during periodic reviews.
- Revocation trigger: Connect removals to the identity source or HR feed where possible, so leavers lose group access without a manual ticket.
- Central control: Keep global roles, text formats and content types with the site administrator, not with group owners.
Confirm with your HR and identity team which system is authoritative for department membership before you design the roles, because that decides whether removals are automatic or manual.
Member communities, such as professional networks or volunteer groups, usually need self-service joining. People request membership, and the group decides whether to accept them or whether joining is open. Revocation is less predictable: members leave voluntarily, lapse when dues or terms expire, or are removed for conduct, so the design needs a clear lapse process.
- Join policy: Choose between open joining, request with approval, or invitation only, and set this per group rather than site-wide.
- Membership roles: Define a basic member role and a moderator role for people who review requests and manage discussion content.
- Approval: Assign approval to group moderators, with a log of who accepted each request.
- Expiry and lapse: Decide how paid-up or renewal-based membership is removed, and whether that happens by script, scheduled review or manual action.
- Central control: Restrict which groups may be created, who can create them, and what personal data members can see in member directories.
Illustrative example: a volunteer association might allow open joining for a regional group but require moderator approval for a group that handles safeguarding content. Ask your community managers which groups need that distinction before you configure join policies.
Partner access is narrow and time-limited. A partner organization may need to upload documents, review drafts or see one project area, and that access should end when the contract or project does. Because partners are outside your normal identity boundary, the accounts, sponsorship and expiry dates need the most explicit design.
- Dedicated partner roles: Create roles with the minimum permissions for the partner's task, with no rights to administer the group or other groups.
- Sponsor approval: Require an internal sponsor who owns the relationship to approve each partner account and each group it joins.
- Time limits: Record an end date for each partner membership and review it before expiry. Confirm how your Drupal setup will remove or disable expired accounts, since core group membership does not by itself enforce an end date.
- Separate accounts: Prefer dedicated partner accounts, or federated sign-in through an identity provider you control, so offboarding is handled at one point.
- Central control: Keep partner accounts out of administrator roles and log every access grant for audit.
Confirm with your legal and security teams how long partner access should last and how a contract end is communicated to the site owner.
Whatever the group model, the site administrator must keep control of the things that affect the whole installation. Group owners should be able to manage their own membership and content, but not change the rules that every group inherits. This tab sets the boundary between group-level delegation and central governance.
- Global permissions: Keep the permission matrix, administrative roles and module configuration under central control.
- Group type definitions: Decide which group types exist and who may create them, so departments cannot create unmanaged groups that bypass review.
- Content and text formats: Restrict text formats, file upload types and embed options centrally so group editors cannot widen security settings.
- Audit and reporting: Review membership changes periodically and keep records of approvals and removals.
- Upgrade ownership: Assign one team to track Group module releases and plan branch upgrades before end of life, since group configuration must survive each upgrade.
Check how your current Group release branch is supported and who will review membership reports, because that owner must exist before the first group is created.
How a Group implementation runs from access design to launch
The sequence turns a community or intranet idea into a Drupal site where each group has its own content, roles and membership rules. Each step produces a written artifact so that the access model is agreed, built, tested and handed over before users arrive.
Agree access and governance rules
Owners from the business, security and the site team meet to write down who may create groups, who approves membership, who can see private content and who answers for a group when its sponsor leaves. The output is a signed access and governance brief that names each group type, its purpose and its accountable owner. The step is done when every group type in scope has a named owner and every question about visibility has a written answer. Ask your partner to challenge the brief with examples of edge cases, such as a partner user who belongs to two groups.
Define group types and role model
The team translates the brief into Group types, such as department, project or partner spaces, and defines the roles each type carries, including group-level permissions for members, editors and administrators. Global roles are kept separate so that site administrators do not inherit group rights by accident. The output is a role matrix that maps every role to the content operations it allows, reviewed line by line by the business owner. Confirm the Group module release and its supported Drupal core version against the current project page before the matrix is final.
Model content types and group fields
Developers decide which content types can be placed inside a group, which must stay site-wide, and which fields carry visibility or classification data. They also decide how group content is shared across groups, so that a page is not duplicated when two teams need it. The output is a configuration export reviewed against the matrix from the previous step, with a short note for each content type explaining its group behavior. The step closes when a reviewer can explain, from the export alone, where each type of content lives and who can change it.
Integrate identity and group provisioning
The team connects the site to the identity source the organization already uses, such as a SAML or OpenID Connect provider, and decides how group membership is granted: manually, from directory attributes, or through an approval request. Mapping rules are written down so that a departing employee loses group access without a manual cleanup. The output is a signed-off identity mapping document and a test run showing that a sample user lands in the correct group with the correct role. Confirm with your identity team which attributes are reliable enough to drive membership.
Load data and create test accounts
Existing groups, members and content are loaded from source systems or spreadsheets, and test accounts are created for each role in each group type. Test accounts are kept out of production user lists and are labeled so that they cannot be mistaken for real staff. The output is a load report that reconciles record counts and flags rejected rows, plus a list of test accounts with the roles they hold. The step is complete when the reconciliation is accepted by the business owner and every test account reflects a role from the matrix.
Write and run permission test scripts
Testers work through a script for each group type, signing in as each test account and attempting the actions the matrix allows and forbids. This covers viewing private content, editing group pages, adding members, and trying to reach another group's content by URL. Failures are logged against the matrix and fixed before retesting, and editorial workflows are included where content must be approved before it is published. The output is a test script per group type with pass or fail results, retained as evidence. The step closes when every forbidden action fails as designed and every failure has a recorded fix.
Launch and hand over the runbook
The configuration is promoted from staging to production through the team's normal release path, and the first groups are opened to pilot users. Before handover, the site team receives a runbook that explains how to create a group, add a member, change a role and remove access, along with the upgrade plan that tracks the Group branch and Drupal core end-of-life dates. The output is a signed handover record listing the runbook, the final role matrix, the configuration export version and the named support owner. Launch is complete when the support owner can add a new group from the runbook without help.
What drives Group module effort and how to keep it down
This table lists the main drivers of scope and cost for a Group-based Drupal site, why each one changes the work, and how to reduce it. Use it to see which decisions move the quote most and what to ask for in a written scope before work starts.
| Driver | Why it changes effort | How to keep it down | What to ask for in a quote |
|---|---|---|---|
| Number of group types | Each group type needs its own fields, content types, permissions and membership rules, and each one multiplies testing. | Limit group types to the structures the organization truly needs, and use one shared type with a category field where behavior is the same. | A list of group types with the content each one owns and the testing covered for each. |
| Roles and permission combinations | Every group role combined with site roles and content permissions creates a matrix that must be designed, configured and verified. | Reuse a small set of group roles across group types and keep the matrix on paper before configuration starts. | A permission matrix as a deliverable, plus the number of roles included in scope. |
| Depth of content sharing between groups | Shared content, cross-group views and inherited access rules add query logic, caching concerns and edge cases. | Share content only where the business case requires it, and prefer links or references over copies across groups. | A written description of each shared content type and which groups can read or edit it. |
| Identity provider integration | Mapping group membership from an external source requires attribute mapping, sync rules and handling of users who leave the source. | Start with local accounts for a pilot, then add SSO and membership sync in a separate phase with a defined source of truth. | The protocol (SAML or OIDC), the identity provider's version, and whether group membership comes from it or only sign-in. |
| Volume of existing users and content | Large membership lists and content estates increase migration time, validation effort and the cost of reconciling duplicates. | Clean and deduplicate source data before migration, and migrate in batches so errors are found early. | The record counts used for the estimate, the migration sources, and the validation method for each batch. |
| Custom code for workflows and access rules | Bespoke approval steps or access logic need code that must be tested and kept working through Drupal core and Group upgrades. | Keep custom code in a single custom module, use configuration and contributed modules where they fit, and document each rule. | Where custom code will live, the test coverage expected, and who maintains it after launch. |
| Upgrade path and branch support | Choosing a Group branch that nears end of life forces a later upgrade project that repeats much of the permission testing. | Confirm the Group branch and Drupal version the site will run, and plan upgrade windows against Drupal's published release schedule. | The supported branch and Drupal version named in the scope, and the upgrade effort included in the support terms. |
How Group connects to identity, editorial and search tools
A Group site is only as useful as the accounts, reviews, search results and shared assets around it. The cards below cover the integration points that most often shape a Group build, and what to confirm for each before the design is fixed.
Single sign-on for group members
Members of departments or partner organizations usually sign in through an existing identity provider rather than local Drupal passwords. The SAML Authentication module (samlauth) lets the site act as a SAML service provider, and the OpenID Connect module can authenticate users against external providers and create accounts on first sign-in. Decide early which module fits your provider, and confirm that the latest stable samlauth release (8.x-3.14, which supports Drupal 10.3 and later and Drupal 11) matches your Drupal version before you commit.
Account creation and group membership
First sign-in creates a Drupal account, but it does not decide which groups that person belongs to. Map identity provider attributes or directory groups to Group memberships and roles through a deliberate process, and test what happens when someone changes teams or leaves. Without this step, access drifts from the source of truth over time. Confirm whether your provider can send the attributes you need.
HR or directory feed for joiners and leavers
Membership changes should follow HR records or directory updates, not manual edits by site administrators. Decide whether changes arrive through scheduled imports, an API call or a sync from the directory, and define what happens to content a removed member created. Check how long removed access stays active after the source record changes, since this is the control auditors ask about most often.
Content Moderation and Workspaces for review
Group content often needs review before it reaches members or the public, and the review rules may differ between groups. Content Moderation and Workspaces are core tools for approval states and staged changes, but their permissions must be planned per group role, not only site-wide. Test the approval path with a real group admin and a member to confirm who can publish what.
Group-aware search with Search API
Search results inside a group should not reveal content from groups a user cannot see. Search API indexes need access checks that respect Group membership, and the index must be rebuilt or reviewed when group access rules change. Confirm how your chosen search backend handles access filters and how long index updates take after a membership change.
Media shared across groups
Shared images, documents and video may belong to a central team but be used inside several groups. Decide whether media lives at site level with group references or inside each group, because that choice determines who can edit, replace and delete assets. Test that removing a group does not break pages that still reference a shared file.
Planning upgrades before the Group branch reaches end of life
Your Group module branch has to match the Drupal core line the site runs on, so the upgrade plan starts with the core version and its end-of-life date. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026, according to the Drupal core release schedule. Those two dates fall close together, so a site on Drupal 10 that plans to stay supported will move to Drupal 11 or straight toward Drupal 12 within a short window. Confirm the current end-of-life and release dates on the Drupal core release schedule before you fix the target, because these dates are the ones that set your deadline.
PHP is the constraint teams most often miss. 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, according to the Drupal.org PHP requirements page. Check the PHP version on every application server and the build pipeline, and confirm that the Group branch and each contributed module in the group stack support the target core and PHP pair. Bugfix releases arrive on the first Wednesday of each month and security releases on the third Wednesday, so budget a standing monthly window for patching the Group module and its dependencies rather than waiting for the major upgrade.
Sites still on Drupal 6 or 7 cannot be updated in place. Drupal.org documentation says they are migrated into a new site using the core Migrate, Migrate Drupal and Migrate Drupal UI modules or Drush, and themes must be rebuilt because they cannot be migrated. Group membership, group content and the group permission matrix have to be mapped into the new site as a separate piece of work, and Drupal 7 security support has already ended, so an interim extended security arrangement may be needed. After every upgrade, whether a patch, a minor release or a major move, re-test group permissions for each role, outsider access to closed groups, and group-scoped content views, because core and contributed changes can alter access results without any visible error.
Questions teams ask before hiring help with Group
What drives the cost of a Group implementation?
The main driver is how many distinct group types, roles and permission rules the site needs, because each one adds design, configuration and testing work. Other drivers include how many existing content types must be placed into groups, whether group content must sync with an identity provider, and how many departments or partners need their own workflows. Cost has two parts: the one-time build (design, configuration, custom code where needed, testing and handover) and any recurring work such as upgrades, monitoring and support. Ask any partner for a quote built from a written scope that lists these items separately, so you can see what is one-time and what recurs.
How long does a Group build take, and why does it vary so much?
Duration depends on scope rather than on the module itself. A site with one group type, a few roles and existing content that fits the model will take far less time than an intranet with many departments, partner access rules, custom group content types and single sign-on. Timing also depends on how fast your role owners make decisions and how quickly sample content and test accounts are provided. Ask for a timeline that is tied to named deliverables in the written scope, and treat any duration that is not linked to those deliverables as unverified.
What does the work need from our team?
Expect to provide three things early. First, named role owners who can approve how each group type, role and permission should behave, because permission decisions are the costliest to reverse. Second, representative sample content, such as a few real department pages, files and events, so the model is tested against actual material. Third, administrative access to your identity provider or directory if group membership will come from it, along with a test tenant or test accounts. Confirm the exact access your environment requires before the scope is signed.
Can an internal team build a Group site without outside help?
Yes, if the team has Drupal development experience, understands the Group module's concepts of group types, roles and group content, and has time to test permissions thoroughly. The risk is less in the first build than in the details: missed permission combinations, custom code that is hard to upgrade, and unclear ownership after launch. An internal team should write down the access model, build a test matrix covering each role against each group type, and review the result with someone who has not built it. Outside help is most useful for design review, complex integrations and a second set of eyes on access rules.
How do we choose the right Group branch?
Choose the branch that is still within Drupal's security support window for the whole planned life of the site, and that matches the Drupal core version you intend to run. Check the Drupal core release schedule for the current major version, the date the version you pick reaches end of life, and the PHP version it requires. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026, so any new build should be checked against those dates. Confirm the module branch that supports your chosen core version with the module's project page before committing.
How do upgrades affect group permissions?
Upgrades can change how permissions behave in two ways: when core or the Group module changes its access checks, and when your own custom code or contributed modules interact with group roles. Permission rules that depend on custom access logic are the most likely to break, so they should be covered by automated or scripted tests. Before each upgrade, run your access test matrix against a staging copy, compare results to the baseline, and document any deliberate changes. Ask your partner how the access matrix is maintained after launch and who reviews it when the module changes.
What does a fixed-scope quote cover?
A fixed-scope quote covers only what is written into the agreed scope: the group types, roles and permission rules to be built, the integrations included, the content to be placed into groups, the testing to be done, the handover documents and the acceptance criteria. It should also state what is excluded, such as ongoing support, later upgrades or content entry. Because DeployOpen does not publish a price list, any quote follows from that written scope. Before signing, ask for each deliverable, its acceptance test and the process for changes that arise during the build.
How DeployOpen scopes and delivers Group implementations
DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted Drupal inside your own infrastructure. For a Group-based community or intranet, that means agreeing in writing which groups, roles and content types are in scope before any build starts.
How we scope
- Engagements are fixed-scope, with the group types, roles and content surfaces agreed in writing before work starts.
- The written scope lists which Group content types, membership rules and permission sets are configured, and which are left out.
- Scope also records the Drupal branch chosen and the upgrade plan that follows its end of life date.
How we build
- Build work covers group types, role and permission matrices, custom group content and access checks in custom modules where needed.
- Permission behavior is tested with test accounts for each group role, including members, outsiders and cross-group visitors.
- Integrations with the identity provider, such as SAML or OpenID Connect sign-in, are built and tested as separate, listed deliverables.
How we hand over
- Handover includes documentation of group types, roles, permissions and the reasons behind each permission decision.
- The configuration is exported so that changes can be reviewed, tracked and redeployed to other environments.
- Your team receives a runbook covering onboarding of new groups, membership changes and how to verify access after an update.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrade work follows the Drupal core release schedule, so the retainer can plan moves before a branch reaches end of life.
- Ask any partner to confirm which Group and contributed module versions they test against before each upgrade.
