New in version 0.9.80
Updated in version 1.1.0: group invite defaults moved to BricksMembers → Groups → Settings, automatic purchase-created group names can use an admin prefix or suffix, native checkout can collect a buyer-entered group name through Member Profile fields, group owners/leaders can rename their group from frontend Bricks templates, and owners can allocate purchased team seats between their own groups.
Whether you’re selling team licenses to companies, running cohort-based bootcamps, or organizing students into classes — the Groups module gives you the structure you need. It brings team management, seat-based licensing, and cohort-based learning into BricksMembers, so you can manage shared access, synchronized schedules, and group discussions without juggling spreadsheets or third-party tools.
Who Uses Groups?
Groups fit a wide range of use cases:
- Course creators — Run cohort-based bootcamps where everyone starts together
- Corporate trainers — Sell team licenses so companies can train their employees
- Universities & schools — Organize students into classes with shared schedules
- Membership sites — Let members form study groups or communities
- B2B SaaS — Provide seat-based access for company accounts
What Are Groups?
Groups are containers for members who share access levels, schedules, and content. Think of them as teams, classrooms, or cohorts where:
- Members automatically receive shared access levels when they join
- Drip content can use the group’s start date instead of individual enrollment dates
- Leaders can manage their team members and review submissions
- Comments and discussions stay scoped to group members only
- Seat-based licensing controls how many people can join
Getting Started
Enable the Module
- Go to BricksMembers → Modules
- Find the Groups card
- Toggle it on and confirm the change
Once enabled, a new Groups menu appears under BricksMembers.
Create Your First Group
You can create groups manually or automatically when customers purchase team licenses.
Manual creation:
- Go to BricksMembers → Groups
- Click Create Group
- Fill in the details: name (e.g. “Spring 2026 Cohort”), type, owner, total seats, default levels, and optional start date
- Click Create Group
Automatic creation via seat rules: Go to BricksMembers → Groups → Seat Rules, create a rule that matches your product, and when someone purchases, BricksMembers records the purchased seats and creates or tops up a group with the purchaser as owner.
For native Payments, the seat rule should select the BricksMembers offer. For WooCommerce, FluentCart, and SureCart, select the connected product, variation, price, or source item from the plugin catalog. Only choose the custom webhook mapping/manual value path when the purchase comes from a generic webhook payload. Generic webhooks can also map purchase quantity; native and same-site integrations send quantity through their own purchase events.
If you want the buyer to choose the first group name during native Payments checkout, add BRM Checkout Fields inside the checkout context and enable its group/team name field. If that value is available when the purchase creates the group, BricksMembers uses it as the initial group name; otherwise it falls back to the generated buyer/type name and any configured prefix or suffix. Existing setups that use a checkout-enabled Member Profile text field mapped to Group name still work as a fallback.
For purchase-created groups, Total Seats means member seats for invited users. The buyer is assigned as the group owner separately, so a plan sold as “5 member seats plus owner” should use Total Seats = 5.
The default fulfillment mode creates a new group for each matching team purchase. Primary-group modes still make sure the buyer always has a group, then add later purchases to the buyer’s first group. Owners can later create additional groups or adjust seat allocations between their own groups from a dashboard that includes the seat allocation panel.
Understanding Group Roles
Each group member has a role:
- Owner — The group creator (or purchaser via seat rule) with full control; cannot be removed
- Leader — Can view member submissions and notifications, and manage invites and members on frontend pages where leader actions are configured
- Member — Standard participant with access to group content
Leaders and owners can review submissions from group members, receive email notifications when members submit work, and view all comments within the group context.
Since version 1.1.0, site admins can also define custom group roles with their own labels, hierarchy rank, capabilities, and data scopes. The default owner, leader, and member roles remain available, but custom roles make broader patterns possible, such as coaches, mentors, reviewers, managers, or parents.
Roles can be allowed to see specific categories of another member’s data, such as learning progress, certificates, or submission summaries. Data scopes can be set to none, assigned members, lower-rank members, or all group members. Use assigned members when one viewer should only monitor specific people, for example a parent assigned to selected children or a coach assigned to selected players.
Managing Members
Open a group from BricksMembers → Groups, scroll to the Members section, and add people by email or by selecting an existing user. Choose the role (Member or Leader) and click Add Member.
On larger sites, the member picker uses a search field with selected-user tags instead of loading the full user directory at once. Search by name, username, or email, then load more results when needed.
If a group is no longer active, archive it instead of deleting it immediately. Archived groups are hidden from the default list, can be revealed with the archived toggle, and can then be permanently deleted if you really want to remove them.
Invitations
You can invite by email or create shareable join links.
Email invitations: Click Invite by Email, enter the address, choose the role, and optionally send the invitation immediately. The invitee receives an email with a unique link; when they click it, they’re added to the group. In limited-seat groups, each pending email invite reserves one seat until claimed, deleted, or expired.
Join links: Click Create Join Link, set optional limits (max uses, expiration), and share the URL. Anyone with the link can join until limits are reached. Join links don’t reserve seats — claims fail if the group is full at claim time.
Custom invitation emails: If you want to change the invitation email text or design, do that in BricksMembers → Emails with the Group Invitation Created trigger. That gives you full control over the invitation subject and body.
When a Group Invitation Created email automation is active, BricksMembers uses that automation for invite delivery and does not also send the old plaintext fallback email on the first invite. Resending an invite runs the same trigger again.
Useful invitation placeholders there include {{group_name}}, {{recipient_email}}, {{claim_url}}, {{inviter_name}}, and {{invitation_role}}. The friendly aliases {{invite_email}}, {{group_invite_url}}, and {{group_role}} work as well.
Custom invite feedback pages: In BricksMembers → Groups → Settings, you can choose a guest redirect page, a post-claim redirect page, and whether BRM should show its built-in success/error notice. If you turn the default notice off, build your own feedback on the redirect page with {brm_group:invite_claim_state}, {brm_group:invite_claim_error}, and {brm_group:invite_claim_message}.
Seats and Capacity
Groups use seat-based licensing: Total Seats is the member-seat capacity allocated to that group, Used Seats is how many member seats are filled, and Available Seats is what’s left. For purchase-created groups, the buyer is the owner and does not consume one of those member seats. When all member seats are used or reserved by pending email invites, new members can’t join until someone leaves, an invite expires or is deleted, or you increase the total.
Purchased capacity is tracked separately as the owner’s seat pool. That means a buyer can buy ten member seats, keep six seats on one group, create a second group with four seats, and later move movable seats between those groups. A group cannot be reduced below active non-owner members plus pending email invite reservations.
Drip Content with Groups
For cohort-based schedules, set a Start Date on your group, create a drip rule, and set Cohort Source to “Group”. The drip uses the group’s start date as Day 0, so different cohorts see content unlock according to their group’s schedule, not their individual enrollment date.
If you want each member to begin their own relative drip timeline when they actually join the group, use the drip trigger Group join instead. In that case BricksMembers starts counting from the member’s group joined_at timestamp rather than the shared group start date.
Private Group Chat
If you also enable the Member Chat module, every group gets a primary chat room automatically. That means a cohort, classroom, or team can have its own private conversation space without you having to wire up a second system by hand.
As members are added or removed from the group, BricksMembers keeps the group room in sync. If the group is archived, the related chat rooms are archived too. So the group itself stays the source of truth, and chat follows that lifecycle instead of drifting away from it.
Building with Bricks
If you build leader-facing invite or member-management forms with Bricks, the BRM group form actions let you decide how success feedback is handled: use the BRM default message, enter a custom success message, or disable the BRM message entirely so the form’s own confirmation or redirect flow owns the UX. Join-link actions also support {join_url} inside the custom success message.
The Group Dashboard, Group Seat Meter, and Group Seat Allocation Panel templates in the BricksMembers Assistant already include the common owner workflows. Rename controls use Update Group Profile (BRM). The starter allocation panel uses Create Group From Seat Pool (BRM) and Update Group Seat Allocation (BRM), so owners do not need to enter raw group IDs. The lower-level Move Group Seats (BRM) action remains available for custom Bricks forms when a builder wants a dedicated source/target move form. Allocation is owner-only; rename and invite actions can be owner/leader actions.
A group dashboard does not have to be a BRM query loop. Normal tags such as {brm_group:name} and {brm_group:available_seats} use the current BRM group context. That context can come from a group query row, a dashboard link with group context, an invitation flow, or the logged-in user’s matching active group for the current post. If a test user only has one matching active group, the page can appear to pick that group automatically.
For layout preview, admins can append ?brm_group_demo=owner to a group dashboard URL. Other preview modes are leader, member, full, and no_seats. These demo parameters are admin-only and intended for layout, dynamic tag, and condition checks. Use a real test group or a sandbox/test purchase for workflows that create invitations, rename groups, remove members, or move seats.
Dynamic Tags
Display group information anywhere with these tags:
{brm_group:id}— Group ID{brm_group:name}— Group name{brm_group:type}— Group type{brm_group:role}— User’s role in the group{brm_group:member_count}— Total active members{brm_group:available_seats}— Remaining seats{brm_group:occupied_seats}and{brm_group:movable_seats}— Seats that cannot be removed and seats that can be moved out of the current group{brm_group:total_seats},{brm_group:used_seats},{brm_group:reserved_seats}, and{brm_group:seat_usage_percent}— Seat totals and utilization{brm_group:pending_invite_count}— Pending invitation count{brm_group:owner_user_id},{brm_group:owner_name}, and{brm_group:owner_avatar_url}— Owner details{brm_group:member_joined_at}— Current user’s joined date in the resolved group{brm_group:invite_handoff_pending}—1or0for invite login/register handoff states{brm_group_member:user_id},{brm_group_member:display_name},{brm_group_member:email},{brm_group_member:role},{brm_group_member:status},{brm_group_member:joined_at}, and{brm_group_member:avatar_url}— Group member loop tags{brm_group:status}— Active, archived, or expired{brm_group_pool:label},{brm_group_pool:purchased_seats},{brm_group_pool:allocated_seats},{brm_group_pool:available_seats}, and{brm_group_pool:group_count}— Owner seat-pool loop values
Conditions
Control element visibility based on groups (all conditions use the user’s active group for the current post):
- Is Group Member — Show when the user belongs to a group that grants access to the current post
- Has Group Context — Same as Is Group Member
- Group Role — Show based on owner, leader, or member role
- Group Status — Show based on group status (active, archived, expired)
- Group Type — Show based on group type (e.g. cohort, team)
- Group Has Seats — Show if the group has available capacity
- User Has Groups — Show if the current user belongs to at least one group
- Group Invite Handoff Pending — Show login/register messaging while an invite claim is preserved through auth
- Can View Target User Learning Progress — Show only when the viewer may see the resolved loop/profile user’s progress
- Can View Target User Certificates — Show only when the viewer may see the resolved loop/profile user’s certificate summary data
- Can View Target User Submissions — Show only when the viewer may see the resolved loop/profile user’s submission summary data
- Target User Progress Percent — Compare the resolved loop/profile user’s progress percentage
Query Loops
Group dashboards use one native User query scope plus two custom query types:
Native User query + Users: Group Membership — List all members of a group. Set the Bricks query type to User, enable Users: Group Membership, and choose Current group or Specific group. For a specific group, use {brm_group:id} or a static ID.
When Users: Group Membership is enabled, BricksMembers also shows group-member filters for roles, membership status, and group order. These controls stay hidden while the membership filter is Off so normal User query loops remain clean.
Inside a User loop filtered by Users: Group Membership, read-only user-aware tags can resolve the looped member instead of the current viewer. That means normal progress tags such as {brm_progress:overall:percent}, safe certificate summary tags, safe submission summary tags, video-watch tags, and the BRM Progress Bar can power privacy-aware member dashboards without custom code. BricksMembers checks the member’s privacy preferences and the viewer’s group-role permissions before rendering another user’s data.
BRM: User Groups — List groups a user belongs to. Enter User ID (leave empty for current user, or use a specific ID). Owner dashboards can filter this query to owned groups and an optional seat rule.
BRM: Group Seat Pools — List the current owner’s purchased seat pools, including purchased, allocated, available, and group counts.
Form Actions
Add a Bricks form and choose from these BRM actions:
- Assign Group Seat (BRM) — Add a user to a group by email; configure group ID and map the email field
- Claim Invitation/Join Link (BRM) — Let users claim invitations; set token source to form field or URL parameter
- Invite Group Member by Email (BRM) — For leaders/owners: send email invitations from the frontend
- Create Group Join Link (BRM) — For leaders/owners: generate shareable join links
- Remove Group Member (BRM) — For leaders/owners: remove a member from the group
- Update Group Profile (BRM) — For leaders/owners: update editable group profile fields such as the group name
- Create Group From Seat Pool (BRM) — For owners: create another owned group from purchased seats
- Move Group Seats (BRM) — For owners: move seats between owned groups that belong to the same seat rule
- Update Group Seat Allocation (BRM) — For owners: set the allocated seats for one owned group without going below occupied seats
The leader/owner management actions require the current user to be owner or leader of the target group. Seat allocation actions are stricter: the current user must be the owner of the affected groups.
Comment Scoping
When the Groups module is enabled, comments are automatically scoped: new comments are tagged with the commenter’s active group, users only see comments from their own group, and admins see all. Posts without group context show all comments normally. This creates private discussion spaces within each cohort.
Group Types
Go to BricksMembers → Groups → Group Types to add types like Cohort, Team, Class, or Study Group. Use them to filter and organize groups.
Common Use Cases
Bootcamp cohorts — Each cohort has its own start date, drip unlocks on that date, students see only their cohort’s comments, and leaders can review assignments.
Corporate team licenses — A customer purchases a team license via seat rule, becomes the group owner, renames the group if needed, allocates purchased seats across one or more owned groups, invites team members into those member seats, and everyone gets access to training content.
Study groups — Create groups in the admin or via seat rules; leaders share join links for self-service enrollment and group-scoped discussions.
Best Practices
- Set realistic seat limits based on your support capacity
- Use expiration dates to auto-archive groups when programs end
- Assign leaders thoughtfully — they have management capabilities
- Test invitation flows and verify email delivery before launching
- Plan group types for consistent organization
Troubleshooting
Members not getting access? Check that the group has default levels configured, the member’s status is “active”, and the group status is “active”.
Invitations not working? Check if the invitation has expired, the user’s email matches (for email invites), max uses hasn’t been reached (for join links), seats are available in limited groups, and guest/post-claim redirect pages are configured in BricksMembers → Groups → Settings.
Drip not using group dates? Verify the drip rule has “Cohort Source” set to “Group”, the group has a start date, and the user is an active member of the group.