Your roster, your own pages, and running more than one intake

Four changes, and the thread between them is that each one stops asking you to retype something you already have.

Fill student groups from your student system

Students pick their own groups during onboarding: first-in-family, commuter, working. Most universities already hold some of that, and asking a student to type it again is both friction and a worse dataset, because plenty of them skip it. Your roster feed can now fill groups for you, one group at a time, switched on from Audiences.

• Send a groups field in your feed, or a groups column in a pasted CSV, using the group's key. A key you have not switched on is skipped rather than treated as an error.
• Off by default, per group, forever.
• Groups that reveal sensitive information need a confirmation first. A group about being LGBTQIA+, Aboriginal or Torres Strait Islander, or neurodivergent is sensitive information under the Privacy Act 1988 (Cth). A student choosing one for themselves is them telling us; your roster sending it is a different act, and the law treats it differently. Before the feed can fill such a group, somebody has to confirm your institution holds the consent to share it, and we record who and when. The database refuses the switch without it, so it is not a convention that can be worked around.
• A student can always leave, and it sticks. Any student can take themselves out of any group on their People page, and no later roster update puts them back. That is the part that makes the rest of this safe.
• The feed never rewrites what a student told you. A membership a student created stays theirs, and their profile shows it came from them.

First Six cannot obtain that consent and does not judge it. If you are unsure whether your enrolment consent covers sharing a group with a third-party platform, leave the feed off for that group and let students choose it themselves. The privacy policy now names roster-sourced groups, and the data processing agreement gained the three commitments above as warranties.

See filling groups from your roster.

Draft Ask Anything answers from your own pages

Your counselling service has a page. So do fees, and IT support. Until now a content editor retyped that into Ask Anything by hand, which is why a new institution's Ask Anything starts thin.

Student resources now has a Sources tab. Name a page, paste its address, press Read, and the console's writing assistant can draft answers grounded in what that page actually says. Every row shows when we last read it, how much text came back, how many answers have been drafted from it, and the error if a read failed. A drafted answer can only link to an address that appeared on the page it came from: if the link you want is not there, the assistant leaves it out and says so rather than inventing one.

Students never see any of this directly. Ask Anything still answers from answers a person wrote and published. We read the page you named and nothing else on your site, when you press Read, with no schedule and no background job.

See connecting your own pages.

Running more than one intake

We went through setting up, delegating and using a second cohort end to end, and fixed the three places it made you work around the product.

• Copy content in. A term's content could only cross into another cohort at the instant that cohort was created. There is now a Copy content in button on each cohort, bringing across its weeks with the dates shifted to the new intake. Copied content arrives as drafts. It is safe to press twice: each week only takes content it does not already have.
• Set or clear one student's start date. On a cohort running on an individual clock, a student's six weeks run from their own date, and that date could only ever be written by the bulk import and never removed. Their profile now has Their start date, with Save and Clear.
• Duplicate to other weeks now includes the week you are in. The dialog had offered the current week for a while and ticking it did nothing, quietly: pick all six weeks and it reported five.

See rolling a cohort over.

An email when a student becomes yours

Assigning a student to a staff member decides where that student's requests go, and it used to happen silently. That person is now emailed: who the student is, which cohort, what the relationship is, and a link to the profile. A bulk assignment sends each person one email rather than one per student.

An email is a notification, not a grant. Being told you are somebody's advisor and being able to open their profile are two different things, and the second is still decided by your permissions and your scope.

See supporters and advisors.