Cohorts and enrollment

A program is the reusable template — its journey, settings, and configuration. A cohort is one running instance of that template with real people on specific (or ongoing) dates. The same program can have many cohorts running at once, each with its own members, its own timeline, and its own lifecycle. In fact, a person is never connected to a program directly — every participant’s link to a program runs through the cohort they belong to and the role they hold there (support receiver, support giver, manager, and so on).

Where membership truly lives

A person’s participation in a program is recorded as a cohort role membership: this person, in this cohort, holding this role, with its own start date, status, and history of who assigned it and when. This one record is the single source of truth the rest of the platform reads — matching, sessions, exercises, goals, and reporting all ask “does this person hold an active role in this cohort?”, nothing else.

A few consequences of this design are worth knowing:

One person can hold multiple roles in the same cohort — for example, someone can be a support giver in a program while also appearing as a manager for another participant. Each role is its own membership record with its own status.
Completion is tracked per role. Someone can finish the program as a participant while their side-role involvement (say, as a manager) continues.
Other views are projections of this truth. Admin screens that group people into intake funnels or matching supply lists are derived views built from the same underlying cohort role memberships — the membership record is the single truth those views are read from and checked against.

Roles within a program and cohort

Every program is built from a small set of role categories:

One Support Receiver role per program. The person being developed (mentee, coachee, leader candidate — whatever the program calls them). A valid program configuration has exactly one Support Receiver role; this keeps matching, journeys, and reporting unambiguous about who “the participant” is.
One or more Support Giver roles. The people providing the development support (mentor, coach, peer). Multiple support giver roles in one program are fully supported — each with its own sessions and its own matching supply.
Optional side roles. People in the support ecosystem but not in the matched pair itself — Manager, second-line manager, HR business partner, and similar. Side roles approve workflows, monitor progress, and provide oversight, but are never matched or pooled.

Managers and HR business partners have a deliberate dual nature: the platform knows them both as an organizational relationship (who is this person’s manager or HRBP in the company, regardless of any program) and, optionally, as a program side role (a named participant in a specific cohort). Both exist side by side — the org-chart fact powers oversight and approvals company-wide, while the side-role membership makes someone an actual participant in a program’s journey.

Role names are per-program display language (a support giver can be labeled “Mentor” in one program and “Koç” in another) — see the roles and terminology page. The role’s underlying category is what drives behavior.

Ways into a cohort

There are four distinct paths by which a person ends up as a cohort member. All of them converge on the same membership record, and all of them trigger the same on-join side effects (agreement forms, approval workflows, 360 activation where the program uses them) — so it never matters later which door someone came through.

1. Direct admin add

From a cohort’s Members page, an admin picks a person and a role and adds them immediately — no invitation involved. The person is a full participant from that moment. Guards apply: archived cohorts can’t be modified, the same person can’t be added twice as an active member, and the role must be one of the program’s configured roles.

2. Bulk import of people

At the organization level, admins can import people in bulk from a CSV or Excel file (name, email, role, department, manager). The import creates or updates the people themselves — including their manager links — using the same guarded account-creation path as any other user creation. Putting imported people into a specific cohort is then a separate, deliberate step (direct add or invitation), so a file upload never silently enrolls anyone into a program.

3. Invitations

Two separate invitation mechanisms exist:

A program invitation — asks someone to join or apply to a program. It tracks as its own record with its own status and does not, by itself, put anyone in the cohort.
A first-login invitation — a distinct one-time link that gets someone into the platform for the first time, separate from the program-invite flow.

Program invitations can carry a validity window — an invitation past its valid-until date shows as Expired. Admins can resend an individual invitation or bulk-resend to everyone still pending, and can also send a program invitation to someone who is already an active member (for example, added manually and never got the email) — none of which changes membership, only the invitation record.

The cohort’s Invitations screen shows the merged picture per person: Sent, Pending, Accepted, and Expired for people moving through the invite flow, plus a “Joined (no program invite)” status for members who were added directly without ever being invited. The screen also summarizes acceptance rate and exports the list to CSV.

4. Marketplace self-service application

Programs can be listed in an internal marketplace where eligible employees discover them and apply on their own. A listing is either open (any eligible person can apply) or shortlist-only (visible only to people an admin has pre-selected). For programs with fixed cohorts, the application window opens a configurable period ahead of the next cohort’s start date and is closed when no upcoming cohort exists; rolling programs accept applications continuously.

An application moves through a defined pipeline:

Draft — the applicant is filling in the application form; progress auto-saves and can be resumed.
Submitted / Under review — the application is with the program’s admins.
Waitlisted — an admin can park a submitted application on a waitlist, with an optional reason. A waitlisted application is still live: it can later be approved or rejected, and it still counts against the applicant’s application limits.
Approved — approval enrolls the applicant: their cohort role membership is created in the destination cohort, in the role they applied for, as part of the same approval action. The destination cohort is either chosen by the reviewing admin or resolved automatically from the program’s intake setup.
Rejected — always carries a reason. The admin can optionally attach a cool-off period: for its duration the person cannot re-apply to that program and role. Once the cool-off ends, re-application is allowed — the new application references the earlier attempt and carries an attempt number, so admins see the full history. The re-apply gate is deliberately strict: while a cool-off is active (or its end can’t be established), a new application is refused rather than quietly allowed.
Withdrawn — the applicant can withdraw their own application any time before a decision.

Application volume is capped from two directions, both counting only live applications (submitted, under review, waitlisted, or approved): an organization-wide limit on how many active marketplace applications one person may have at once, and a per-program limit on active applications to the same program and role. Either limit being reached blocks new applications with a clear message; resuming an existing draft is always allowed.

Invited vs. enrolled

The two states usually move together — an admin adds someone and sends the invite in the same action — but they are checked separately, and the platform is strict about which one is the “on” switch. Features like matching, sessions, and reporting look at active cohort membership, not at whether an invitation was ever sent or accepted. Someone who was invited but never became an active member does not show up as a participant anywhere else in the system; someone added directly with no invitation at all is fully a participant.

Cohort lifecycle: the group as a whole

A cohort itself moves through a small set of states, generally in one direction:

Prep — the cohort exists but hasn’t started yet. Admins use this stage to add members, send invitations, and work through a setup checklist before going live. A Prep cohort with no members can still be deleted; after that, cohorts are only ever archived, never erased.
Active — the cohort has started and its members can use the program’s features.
Completed — the cohort’s end date has passed, or an admin manually marked it complete.
Archived — the cohort is deactivated and treated as a historical record; it can still be viewed but is out of the day-to-day list.

Moving a cohort through these stages is a deliberate, guarded action — a cohort can only be activated from Prep, only completed once it’s active, and only archived once it’s completed. Every lifecycle action re-verifies that the acting admin’s organization actually owns the cohort, and repeating an action that already happened is safely reported rather than re-applied.

Member lifecycle: the individual within a cohort

Separately from the cohort’s own state, each member has their own status inside the cohort, reflecting their personal progress through the program:

Pending — assigned to the cohort but hasn’t started participating yet.
Active — actively taking part, with full access to program features.
Completing — has started the process of wrapping up (a closure workflow), pending final confirmation. Depending on program settings, an early/premature completion request can require a program manager’s or HR’s approval before it’s finalized — while awaiting that approval, the member sits in a distinct “pending approval” state.
Completed — has finished the program successfully.
Withdrawn — left the program before completing it, whether by choice or removal. A withdrawn member can later be reactivated back to Active if appropriate.
Archived — a historical record kept after the program/cohort’s active period has ended.

Only certain moves between these states are allowed (for example, a member can go from Active to Completing and back to Active if a closure is cancelled, but can’t jump straight from Pending to Completed) — this keeps the member’s status trustworthy for reporting and for anything else that reads it.

Removing someone also comes in two clearly separated sizes: removal from the cohort (this membership only) and removal from the whole program — the latter shows the admin a preview of everything the removal will touch before they confirm.

Fixed-date vs. rolling cohorts

Cohorts come in two flavors, depending on how the program is meant to run:

Fixed cohorts — the traditional model, with a set start date and end date shared by everyone (think “Class of 2025”). Milestones, matching, and reporting are organized around that shared calendar.
Rolling cohorts — used for “on-demand” programs with continuous enrollment. There’s no shared start/end date; instead, each person’s own timeline is measured from their individual start (for example, a milestone at “day 30” or “day 90”), and people can join a queue rather than waiting for a batch. A cohort is recognized as rolling simply by not having fixed start/end dates set. Rolling cohorts have their own status view showing each person’s expected end date and progress, and admins can grant individual extensions (with a reason, for the record) or bulk-populate expected end dates from the program’s configured duration.

Even though rolling cohorts behave differently day-to-day, they are still the same kind of cohort underneath — just with individual, rather than shared, timelines.

Timeline and milestones

Every cohort carries a timeline of milestones — the named checkpoints that anchor the program journey (kick-off, mid-program checkpoint, closing, plus any custom milestones a program defines). Milestones organize what participants see of the journey ahead, and they drive the program’s scheduled reminders and communications. On fixed cohorts, milestone dates hang off the shared cohort calendar; on rolling cohorts they are expressed as day-offsets from each person’s individual start. Admins review and adjust the cohort’s milestone plan from the cohort’s Timeline area.

What can be tuned per cohort

A cohort inherits everything from its program, and can override a deliberate short list of things:

Session location options — a cohort can narrow the program’s allowed session location types and set a different default (for example, an all-remote cohort of an otherwise hybrid program).
Branding — a cohort can carry its own branding override on top of the program’s look.
Capabilities (permissions) — what each role is allowed to do can be overridden at three levels, and the most specific one wins: cohort overrides beat program overrides, which beat company overrides, which beat the role’s defaults. Each cohort has its own capability matrix screen, and an admin can copy the finished matrix from another cohort instead of rebuilding it.
Prep checklist — beyond the built-in readiness signals, each cohort can carry its own custom checklist items and manual overrides, so different programs define “ready to launch” in their own terms.
Milestone plan — the cohort’s milestone dates and custom milestones, as above.

Everything else — the journey content, forms, matching rules, terminology — is configured once at the program level and shared by all of its cohorts.

What admins see per cohort

Each cohort has its own workspace in the admin area, opening on a hub that summarizes the essentials — member counts by side (support receivers, support givers, managers), matched pairs against possible pairs, session totals and completions — alongside the lifecycle actions (activate, complete, archive). From there, dedicated per-cohort areas cover:

Members — the live roster with each person’s role, status, match partner, and join date; per-member actions (change role or status, send either kind of invitation, remove from cohort or program, mark closed and revert); bulk actions (bulk remove, bulk role assignment); and CSV export of the roster.
Invitations — the merged invited-vs-joined picture described above, with resend, bulk resend, acceptance-rate stats, and CSV export.
Matching — the cohort’s matching runs and pair management.
Sessions — the cohort’s session activity.
Timeline — the milestone plan.
Prep — the pre-launch checklist (auto-detected readiness signals — members added, invitations sent, matching done, exercises and session settings configured, welcome content set — plus manual check-offs and custom items).
Rolling status — for rolling cohorts: each person’s expected end date and progress, individual extensions, and bulk end-date population.
Handshakes, 360 feedback, assessment results, communication — the cohort-scoped views of those program features.
Capabilities — the cohort’s permission override matrix.
Archive — readiness check and archive history.

Preparing and archiving

Before a cohort goes live, its Prep checklist tracks a mix of auto-detected readiness signals (has anyone been added, have invitations gone out, is at least one match made, are sessions and exercises configured, is a welcome message set) alongside items an admin can manually check off or add as custom to-dos.

Once a cohort has run its course, the Archive workflow gives an admin a readiness check before archiving, lets them record a reason, provides a “force” option for exceptional cases, and keeps a visible history of past archive/unarchive actions — with the option to bring a cohort back and reactivate its members if it turns out to have been archived too early.