/
Mutual Exclusivity in User Groups

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

  1. Enrollment Tracks

    • G1: Users in the Audit track

    • G2: Users in the Honor track

    • G3: Users in the Verified track

  2. Course Engagement

    • G1: Students with course progress < 30% or no login in the last 10 days

    • G2: Students who do not meet that condition

  3. 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.