Mutual Exclusivity in User Groups
Overview
When we talk about mutual exclusivity in this context, we’re referring to the restriction that a user cannot belong to more than one group within a defined set. This is necessary to:
Avoid duplicated information
Deliver different types of content based on group membership
However, taken as-is, this rule presents a challenge. Since group membership is based on conditions, a user should be able to belong to more than one group, and a user may easily match more than one. This document explores how we can implement mutual exclusivity for some groups while allowing others to overlap.
Key Concepts
Group Collection
A Group Collection is a set of groups that are mutually exclusive with one another. Collections can be:
Automatically created based on dynamic rules
Manually defined by course staff or admin users
Each group belongs to a collection. By default, every group is placed into a "default" collection with two groups:
Users who meet the condition
Users who do not
Some collections are predefined by the system. For example, the Enrollment Track collection includes groups such as:
Audit
Honor
Verified
These are inherently mutually exclusive. Each user is in exactly one track.
Examples of Mutually Exclusive Groups
Enrollment Tracks
G1: Users in the Audit track
G2: Users in the Honor track
G3: Users in the Verified track
Course Engagement
G1: Students with course progress < 30% or no login in the last 10 days
G2: Students who do not meet that condition
Manually Defined Roles
G1: Beginners
G2: Intermediates
G3: Advanced learners
In each case, users can only belong to one group within the collection, ensuring clear targeting and content delivery.
Design Guidelines
Groups within the same collection are exclusive by definition.
If you need groups that are not mutually exclusive, it’s recommended to create separate flat groups that do not belong to a shared collection.
This approach allows us to:
Preserve mutual exclusivity where needed (e.g., for content gating)
Allow flexible membership in other scenarios (e.g., tagging or segmentation based on user behavior)
By introducing collections, we gain better control over how exclusivity is applied across different types of groups.
Comments
On first glance, I don’t believe I as a course delivery team member would necessarily need to see anything about this if I create a user group:
For example: If, I create a user group of learners who haven’t engaged with any course pages in 7 days.
I don’t think I’d expect a group to automatically be created and visible to me in the UI that is a group of learners who have engaged with any course pages in 7 days.
I don’t think I’d expect to see a Group Collection name or IDs for each of these user groups to be visible to me in the UI.
Do you agree?
Exactly, I don’t really think it’d be necessary to show the default groups to the course team. The course team would link content directly to the groups within the collections, just like teams and team-sets currently work right now:
We’d definitely need to improve the Team set Team set B groups, so only shows “Groups” and then “Group Collections”.
However, once we start allowing user groups to be linked to content groups, we’ll need a way to indicate that the groups I’ve created are part of a collection, membership for each of these user groups in a collection is mutually exclusive, and I can link each of these user groups to a different content group as I would for a cohort. Is this how you imagined it as well?
Do we envision that Group Collections could act as Team Sets down the line?
Yes, and yes! The group collections idea is very similar to how team sets work, but the rebranding helps to understand their end goal better.
I could expect that users would want to be able to name Group Collections to be able to easily identify and organize them.
Totally. For example:
Company X
Managers
Engineers
Interns
Language Track
English
Spanish
French
Topics of interest
Machine Learning
Cybersecurity
Data Science
I was imagining users could select the group collection and send notifications, or only to a subset of their groups (this might overcomplicate things though). Content gating would be associated with each group.
If the groups within a group collection could be used as cohorts… it may be a need (in the future) to create a Group Collection and then specify that I want to be able to create N distinct and randomly assigned groups within this collection (similar to how a user can create random cohorts for testing out course content through randomized A/B testing).
Yes! I think canvas or moodle offers the ability to create a number of random groups , for example
Excellent - it sounds like we’re both on the same page here. Sounds good to me!
This makes sense to me as a great way to tackle this problem.
On first glance, I don’t believe I as a course delivery team member would necessarily need to see anything about this if I create a user group:
For example: If, I create a user group of learners who haven’t engaged with any course pages in 7 days.
I don’t think I’d expect a group to automatically be created and visible to me in the UI that is a group of learners who have engaged with any course pages in 7 days.
I don’t think I’d expect to see a Group Collection name or IDs for each of these user groups to be visible to me in the UI.
Do you agree?
However, once we start allowing user groups to be linked to content groups, we’ll need a way to indicate that the groups I’ve created are part of a collection, membership for each of these user groups in a collection is mutually exclusive, and I can link each of these user groups to a different content group as I would for a cohort. Is this how you imagined it as well?
Do we envision that Group Collections could act as Team Sets down the line?
These are not items we’ll need to immediately solve for, but thoughts I had while reviewing this:
I could expect that users would want to be able to name Group Collections to be able to easily identify and organize them.
If the groups within a group collection could be used as cohorts… it may be a need (in the future) to create a Group Collection and then specify that I want to be able to create N distinct and randomly assigned groups within this collection (similar to how a user can create random cohorts for testing out course content through randomized A/B testing).