Onboarding an institution, end to end
Standing up a new institution is a setup process, not a self-serve sign-up. This guide walks the whole path — from a signed agreement to the first student signing in — and shows how the institution, IT, and First Six each play their part. It is the cross-cutting companion to the institution-facing implementation overview and the developer setup docs.
The order matters: each step depends on the one before it. Do them out of order and SSO will fail in a way that looks mysterious but isn't.
1. The tenant and its slug
Every institution is resolved by a slug, not by hostname. The slug is the stable identity everything else keys off — branding, links, and data isolation — so it is chosen carefully and rarely changed.
The product works the moment the slug and brand exist. A vanity subdomain like
unisc.firstsix.com.au is an optional later step involving DNS, not a prerequisite
— see custom subdomains.
2. Branding
The institution's logo, colours, and copy go in. From this point the student and staff experiences look like the university's own, not a generic tool. Because tenancy is slug-based, branding is live without waiting on any DNS change.
3. The roster, via SIS sync
The institution's student and staff records are loaded through SIS sync: a bearer-authenticated endpoint that is idempotent, rate-limited, and capped per request, so it is safe to run on a schedule and safe to re-run.
This step exists before SSO for a reason: the people have to exist in the system before anyone can sign in as them.
SSO links a sign-in to an existing record — it never creates one. If you wire SSO before the roster is synced, the first login fails with no obvious cause. Sync first.
4. Single sign-on
If the institution uses SSO, it is wired now as custom OIDC with PKCE. The key rule, covered in full in the OIDC flow and the dedicated SSO guide: claiming an SSO identity links to an actor that already exists from the roster sync. It does not create one.
IT can verify the wiring before launch without exposing it to students — see testing SSO before launch.
5. The first cohort
With people in the system, staff create the first cohort and choose which features apply to it. This is where the abstract tenant becomes a real group of students with a real first-six-weeks experience.
6. Go-live
Students sign in (via SSO or direct), land in their branded workspace, and the first-six-weeks arc begins. Staff watch the cohort pulse and respond through the inbox.
What a clean onboarding guarantees
- Data is isolated from day one, because every record carries the tenant's identity and the database enforces it.
- No one can sign in as someone who isn't on the roster, because SSO links rather than creates.
- The university's brand is live immediately, with a custom subdomain available later if wanted.
Common questions
Can a university onboard itself without us?
Not today. Tenant creation, branding, SSO wiring, and the roster connection are setup steps. The institution provides the inputs (IdP details, SIS access); the provisioning is done for them.
Why does SIS sync come before SSO?
Because SSO links a login to an existing student or staff record and never creates one. The roster has to be present first, or the first sign-in fails.
How long does a custom subdomain take?
It is independent of go-live. The slug-based setup is fully working first; the subdomain is added when DNS is sorted, with no downtime. See custom subdomains.
Related
The fastest answer is usually one question away.