Creating a new cohort

A cohortOne run of the first six weeks for one group of students, usually a single intake. is one run of the first six weeks for one group of students. Each intake gets its own. Keeping intakes separate is what lets you run them at different times, with different content, without one bleeding into another. Here is how to create, populate, and manage them.

Create

Click New cohort and fill in the basics: a display name, the intake start date, and how many weeks the cohort runs. You start with an empty student list; students are imported or join when they first sign in.

The start date and week count are what anchor the six-week arc. Content scoped to a week number resolves against this start date, so getting it right up front means your scheduled and week-scoped content lands when you expect. A wrong start date shifts the whole arc.

The New cohort drawer also lets you set the key dates (semester start, semester end, and census date) right there, so the first thing your setup guide checks is already done. They're optional at this step; leave them blank and set them later in Term setup if you'd rather.

Clone from a previous cohort

If you ran a cohort last intake, clone it. Cloning copies the events, to-dos, briefings, and templates from the source cohort into the new one, so you start from last term's structure instead of a blank slate. The console remembers what you cloned from and tailors its setup guidance accordingly.

Copied content arrives as drafts, with dates shifted to your new intake. Nothing the clone brings across is visible to students until you review and publish it. So a freshly cloned cohort looks empty to students until you flip Week 1 live. That's deliberate: it gives you a chance to prune and re-target before anything ships.

1. Pick the closest previous cohort

   Clone from the intake most like this one, so the structure you inherit needs the least reworking.

2. Walk the weeks

   Go week by week and update dates, names, events, and anything tied to the last intake that has since changed.

3. Prune what no longer fits

   Remove content that was specific to last term. Cloning gives you scaffolding, not a finished build.

Import students

Bring students in with a CSV. Give it a header row and the columns are matched by name in any order, including the names your student system already uses, so an export can usually go in unedited: student_id, email, first_name, last_name, program_code, campus, and an optional start_date. Only email is required. Cells can be separated by commas, tabs or semicolons, so pasting rows copied straight out of a spreadsheet works as well as uploading a saved file.

Include student_id whenever you have it. It is your own student number, so it lets a later import find someone whose email has changed, and it is what a student-system feed matches on. If you run rolling terms it is not optional: per-term enrolment matches students by that number alone. Name the column student_id (or student number, SIS ID, SID); a bare "id" is deliberately not read as the student number, because it is so often an internal row key instead, and a "usi" column is never read either, because the Unique Student Identifier is a national government number rather than your own.

If your report gives you one combined name column rather than separate first and last names, paste it anyway. "Nguyen, Alice" is read exactly as written; anything else is split at the first space, and the preview tells you how each name was read so you can check it before importing.

The importer validates each row's email format, matches and de-duplicates existing students by email, and reports success or failure per row, so a bad line does not silently drop a student.

The per-row reporting is the part to actually read. The importer does not stop at the first bad row, so a partial import can succeed while a handful of students quietly fail validation. Check the failure report and fix those rows rather than assuming a finished import means everyone made it in.

Importing also sends each new student a one-time, institution-branded invite email ("you're set up, here's your sign-in link") by default; untick Email invites after import in the drawer to hold them back, for example when you're loading a roster months before the term starts. Already-invited and already-active students are never re-emailed, so re-imports are always safe. The drawer's Invite emails card shows who is still waiting, sends to them on demand, and can email you a preview of the exact message first.

Archive

When a cohort is finished, archive it. Archiving is a two-step confirm that shows you the impact first. Archived cohorts move to their own section with all their data intact and searchable; they just drop out of the active switcher.

You cannot archive your last live cohort (the console will not leave you with nowhere to stand), and archiving the active cohort automatically switches you to the next live one. The two-step confirm exists because archiving touches a whole intake's worth of context at once; the impact screen is there so you act on what it will do, not what you assume it will do.

Switch the active cohort

The sidebar shows your active cohort. Click it to switch. The whole console (inbox counts, insights, authoring) re-scopes to the cohort you pick, and a toast confirms the switch. Your choice is remembered, so the console opens where you left off.

This is why the inbox or insights can look different from a colleague's: you may simply be scoped to different cohorts. If the numbers seem wrong, check which cohort is active in the sidebar before assuming anything is broken.

Troubleshooting

Common questions

Next steps

Related