Get your cohort ready
Staff see this same walkthrough inside First Six under Guides & Articles → Get your cohort ready. This is the reference copy.
This is the path from a fresh tenant to a live first cohort. Almost nothing in the platform self-assembles. Every weekly briefing and every event started as a deliberate decision someone made here (the weekly check-in is the exception: it comes standard, ready to go). The work is real, but the order matters more than the volume, which is what this guide does for you.
Ten steps across three groups: setting up the cohort itself, building the content students will see, and launching. The first group is the foundation everything else sits on. Get the term dates wrong and every week's date range needs rewriting later. The second group is the bulk of the actual work. The third group is the launch, and is mostly verification.
About 90 min · Setup checklist.
Institution admins setting up a new cohort for the first time.
Now, if you're launching. Subsequent terms switch to the Rollover guide.
Inside the console most steps tick automatically as the platform detects them; three verification steps (brand, audiences, student resources) you tick yourself. Here in the reference copy you tick them all yourself. The boxes below are saved in this browser, so you can close the tab and pick up where you left off.
Set up your cohort
Dates, brand, students, audiences.
Set your term dates and key dates
Your cohort's term dates are the spine of every other piece of timing in First Six. Week 1's date_start is computed from the semester start, the cohort pulse compares against the live week, the census date drives the support-for-students reporting window, and every event you import or sync needs to land inside a week to be visible.
Set these once, up front. Getting them wrong later means rewriting every week's date range by hand.
Walk through it
In the console: Open Term setup.
Set your brand
Make the apps look like yours. In Settings → Brand identity you set your one accent colour and upload your logo yourself; saving re-themes the whole student and staff experience the next time a page loads, with no redeploy. Dark mode is handled for you: the apps brighten your accent so it stays readable on a dark background, and a live preview shows both the light and the dark result as you go.
Just below, the Email sender section lets you set the name your emails show as (for example "UniSC Student Life") and a reply-to address for your general student emails (invites, check-in and pulse reminders). Help-request emails do not use it: a student replying to one of those replies into their own request, so the conversation stays in one place and on the record, and staff notifications point at the thread in the console rather than at anyone's mailbox. The one thing still arranged with your First Six contact is having emails come from your own domain, which needs your DNS verified with our mail provider (SPF/DKIM). Crisis alerts are never affected by these.
Tick this step once your colours and logo look right against both light and dark backgrounds.
Walk through it
In the console: Open Settings.
Bring in your students
Needs: set your term dates first.
Access is roster-first: a student gets in when you've added them, and their pre-provisioned account goes live the moment they first sign in. (Self-serve enrolment by email domain exists as an explicit opt-in your First Six contact can enable; it is off by default.) Importing is what lands each student in the right cohort with program, campus and start-date data. The Cohorts page has a bulk import drawer that takes either an uploaded .csv file or pasted rows.
Paste your own export. If your file has a header row, columns are matched by name, in any order, and we recognise what student systems actually call them: student_id / student number / SIS ID / SID, email / email address, first_name / given name, last_name / surname / family name, program_code / course code, campus / location, start_date / commencement date. So a Banner, Callista or TechnologyOne extract can usually go in unedited. If your report has one combined name column instead of separate first and last names, that works too: Nguyen, Alice is read exactly, and anything else is split at the first space, with a note in the preview telling you how each name was read so you can check it. Cells can be separated by commas, tabs or semicolons, so copying rows straight out of a spreadsheet works as well as a saved .csv. A plain list of emails, one per line, also works.
One column we deliberately do not read as the student number: a bare id. That name almost always means an internal row key rather than the student's own number, and quietly importing it would break enrolment matching later with nothing to point at. If your export really does call the student number id, rename that one column. The preview says so when it sees it. We also never read a usi column: the Unique Student Identifier is a national government number, not your student number.
Only email is required; everything else is optional. But include student_id whenever your export has it. It is the number your own systems already use, so it lets a re-import find someone whose email address has changed, it is what a student-system feed matches on, and if you run rolling terms it is essential: per-term enrolment matches students by that number and nothing else. Import a roster without it and every enrolment row will come back as an unknown student.
program_code is matched to a program by its code, campus to a campus by its name. start_date (yyyy-mm-dd) only matters for an individual-clock cohort. It anchors that student's own six weeks; leave it off and the student rides the cohort clock.
Without a header row, the columns are read in this order: email, first_name, last_name, program_code, campus, start_date. Student numbers can only be supplied by a named column, so use a header row if you have them.
Existing students in the institution are matched on email and updated in place. You don't need to dedupe upstream. New emails get a pre-provisioned identity that goes live the first time they sign in via SSO. Re-importing with student_id present fills it in for students already on file, so it is safe to add the column later and import again.
Walk through it
In the console: Import students.
This is the one step the platform will refuse to let you take early. Until at least two people at your institution hold the Support responder or Admin role, the Invite emails card will not send, and it will say so.
The reason is blunt: a student can raise a crisis in their first minute in the app, so the people who answer one have to exist before anyone is let in. One person is not a rota either, because they sleep, take leave and eventually leave the university, and until they do the console looks perfectly healthy.
Importing students is never blocked, and neither is emailing yourself a preview. Only the invite that gives real students access waits. Fix it in Team, then come back. Settings → Crisis shows you the same picture at any time under Who gets told.
Check your audiences and groups
Audience tags are how you target a what-matters block, todo, or event at a subset of students. By program, by campus, by year level, by first-in-family status, by anything you defined. The list of tags is built from your student data on import; this step is verifying that the right tags exist and that the ones you actually plan to target are enabled.
If a program or campus is missing from the list, students probably weren't imported with that field. Go back to the import step and re-run.
Walk through it
In the console: Open Audiences.
Build your content
Weeks, events, resources, maps.
Build your weeks
Needs: set your term dates first.
The weekly arc is the heart of the student experience. Six weeks by default, and up to 26 if your programme runs longer. Each week has a heading ("Week 3: settling in"), a what-matters block (the thing students should remember from this week), and a top to-do (the one thing they should actually do).
Start from a template if you have one. They're at /templates and you can clone the whole shape in one click. Then edit each week's copy in place. The Cohorts & Student Import page tracks completion: this step ticks when every week from 1 to weeks_count has at least one published week_block.
Walk through it
In the console: Open Briefings.
The weekly check-in (nothing to build)
Each week, students answer one wellbeing check-in question. Their responses aggregate into the cohort pulse: the calm signal that tells you what's going on for the group without surveilling any individual.
There is nothing to set up here. The question is the same for every university and every week ("How's this week landing for you?"), and the answer options are standard too, each mapped to a pulse band. That consistency is deliberate: it keeps the pulse comparable week to week and cohort to cohort. New cohorts come with the check-in already in place. The pulse only fills in when a meaningful number of students have answered; First Six suppresses small-N reads so a quiet week doesn't read as a crisis.
Add events for each week
Needs: build your weeks first.
Events are the dated things students can show up to: orientation, drop-in support, social meetups, workshops. Three ways in:
- Manually create them on /events (best for a handful per week). 2. Bulk import a CSV (best for an existing schedule). 3. Connect your existing campus calendar with the iCal sync, so events pull in automatically (best when the calendar already exists upstream). Set it up in Settings → Integrations → Events feed; the Events page also links to it for anyone who can reach Settings.
Each event carries audience targeting like the what-matters blocks. Use that to surface a tutoring drop-in only to first-in-family students, or a program-specific welcome only to that program's cohort.
Walk through it
In the console: Open Events.
Curate your student resources
Student resources is the always-available reference layer that sits underneath the weekly arc. It carries three things: resources (external URLs students hit often like the LMS or the timetable, plus PDFs and longer references), Ask Anything answers (a curated FAQ that backs the search bar), and help routes (the categorised pathways students take when they need a hand, including the crisis protocol).
Sweep through each section once. Resources can usually be done in twenty minutes. Ask Anything is worth two hours of effort because every answer here is one fewer help ticket. Help routes are the safety net; the crisis route in particular MUST be configured before any student touches the platform.
Walk through it
In the console: Open Student resources.
Add your campus maps
Campus maps are images (PNG, JPEG or WebP, up to 10 MB) students pull up on their phone, with pinch-zoom. Each map gets a campus and a clear label: use labels like "Accessibility map" so students can spot the right one.
Walk through it
In the console: Add maps.
Launch
Team, targeting check, go live.
Set up your team
More than one staff member needs access before you can go live. Responders see the inbox and triage help requests; editors can draft and publish content; institution admins can do both plus tenant settings.
Each responder also carries a scope: institution-wide, by cohort, by degree, or by campus. A responder scoped to one campus only sees that campus's help tickets. Scopes are how you keep a Director's view separate from a teaching assistant's. A responder you give no scope to sees every student in the institution, so set one for anyone who should only look after part of it.
Walk through it
In the console: Open Team.
Double-check your audience targeting
Needs: build your weeks first.
Before you flip Week 1 to published, read it back and confirm every item is pointed at the right students. Each what-matters block, to-do, and event carries an audience label in the composer and the content lists. This is the moment to make sure each one says what you intended. Because audience facets combine with AND, an over-tagged item is easy to create and quietly invisible to the students who need it, so it's worth a deliberate pass.
What you're looking for: does the what-matters block read clearly to a first-time student? Does the top to-do actually have a clear action? Is each event targeted at the students who qualify for it? Does the help route someone would reach for if anxious actually exist?
Nothing is visible to students until you publish it, so you can build ahead and re-read as much as you like first. Tick this step once you've walked Week 1 top to bottom and every item's targeting reads right.
Walk through it
In the console: Open Briefings.
Publish week one and go live
Needs: build your weeks first.
This is the trigger. Once Week 1's content is published, any student who signs in to First Six will see it. The cohort is live.
Open Briefings → Week 1 and confirm the what-matters block, the top to-do, and any events you want visible are all status='published'. The completion check here is just: does at least one week_block for week 1 have status='published'? But you'll want everything for week 1 published, not just one block.
Walk through it
In the console: Open week 1.
Related guides
The fastest answer is usually one question away.