Roles and access
First Six keeps access deliberately simple: a small set of roles, plus a scope that limits which students a person sees. Together they make sure staff have exactly the reach their job needs, and no more.
The roles
There are three built-in roles you assign inside your institution, plus any custom roles your admins create. Each built-in role is sized to a real job rather than a sprawling permission list:
| Role | What it's for |
|---|---|
| Institution admin | Running the show. Settings, the team, the audit trail, every cohort. |
| Content editor | Building the student experience, across the whole institution. Authoring, not responding. |
| Support responder | Looking after students. The inbox and cohort wellbeing for their scope. |
Most people are a responder or an editor. Admins are few by design.
There is also a fourth role, platform owner, First Six's own operations and support staff. It has full access across every institution and exists for vendor support, so it is not assignable inside your account.
What each role can do
The exact capability breakdown. "Their scope" means the slice of students set for that person (see Scope below). Admins and content editors are never scope-limited.
| What they can do | Institution admin | Content editor | Support responder |
|---|---|---|---|
| Build & edit content (briefings, events, resources, announcements, check-ins, campus maps, templates) | Yes, all cohorts | Yes, all cohorts | No |
| Work the help inbox (read, reply, triage, notes, reassign) | Yes | No | Yes, their scope |
| Escalate a ticket to crisis | Yes | No | Yes |
| See individual student records (profile, check-in history) | Yes | No | Yes, their scope |
| Aggregate engagement insights (how a cohort is tracking) | Yes | No | Yes, their scope |
| Manage the roster (import students, assign cohorts) | Yes | No | No |
| Export the evidence pack | Yes | No | Yes |
| Change institution settings (term dates, profile, crisis routing, crisis distress signals) | Yes | No | No |
| Manage the team (add staff, set roles & scope, deactivate leavers, sign people out) | Yes | No | No |
| View the audit log | Yes | No | No |
Two lines worth calling out: content editors are pure authors: they build content for their scope, but they don't work the help inbox, see individual student records, read cohort insights, manage the roster, or export the evidence pack. And support responders can't author content: they respond, they don't build. The platform-owner role can do everything in this table, across every institution.
The Mark as crisis action in the ticket drawer is visible to institution admins, support responders, platform owners, and any custom role granted the respond-to-crisis permission: the roles on the response line. Content editors don't see it, because they're on the authoring line. See the limits of automated detection for how the escalation works.
Scope: who sees which students
Support responders carry a scope: the slice of students they work with, set by degree, campus, or cohort. A responder scoped to one campus sees that campus's requests and pulse, not the whole institution's. This is the control that decides who can read a distressed student's message, so it is the one place scope genuinely protects somebody.
Content editors do not carry a scope. They write for the whole institution. Scoping them answered "which weeks of the arc may this person write", which is not a question universities ask, and requiring an answer meant a new editor could edit nothing until somebody supplied one. It was never a student-data control either: a content editor cannot open a student record at all, whatever their scope said, because the role carries authoring permission and nothing else.
If you do want an editor confined to one degree or campus, build a custom role at Settings → Roles. Custom roles keep scope, so that still works.
Institution admins have full reach. Content editors have full reach over content and none over students. Responders are bounded by their scope, so the inbox, the cohort browser and insights each show only the students they are responsible for.
How it's enforced
Enforcement does not stop at what the interface shows. Permissions are checked in the database on every action, deny-by-default, so a role can't reach past its line even through a crafted request, and one institution can never see another's data. Scope narrows visibility once it is set; a responder with no scope set sees the whole institution within their role, which is why the team page warns when one is missing. The governance-level account, for the people who sign off on access, is in who can see what.
Managing the team
From the team area, an admin can:
- Add staff and set their role
Bring a colleague in as an admin, editor, or responder: one at a time with Invite staff, or a whole team at once with Import from CSV (one row per person: email, and optionally role and name). Either way they get access the first time they sign in with your university SSO. There's no invite email to chase and no password to set. Bulk import is the right tool for initial onboarding; the single invite is for the occasional new starter later.
- Set their scope
Point them at the degrees, campuses, or cohorts they cover.
- Reassign work when someone's away
When a staff member goes on leave, their open help requests can be reassigned to others, with a handoff note that travels with each ticket so context isn't lost.
- Deactivate someone who's left
When a staff member leaves, deactivate them from their card. Their access ends immediately (live sessions are cut and their university SSO sign-in stops working here), and any open requests they were holding return to the queue (reassign first if you want them to land with a specific person). Everything they built and the audit trail are kept, and you can reactivate them later if they come back. Safety rails: you can't deactivate yourself, and you can't deactivate the last remaining admin.
Troubleshooting
A colleague cannot see the inbox at all
Their role, working as designed: the triage inbox is restricted to responders and admins, and content editors never see it, because reading students' help requests is a bigger thing than writing week content. If they should be triaging, change their role on the Team page.
Deactivating someone warned me about their open requests
The console counts the open help requests they are holding and says so before you confirm, because those tickets return to the unassigned queue the moment they lose access. Reassign the tickets first, with a handoff note, and the warning has nothing to warn about.
I deactivated the wrong person
Reactivate them from the Deactivated list on the same page. Nothing was lost in between: their content, their history and the audit trail all stay intact through a deactivation, which only removes their ability to sign in.
Common questions
Can a content editor see help requests or a student's details?
No. Editors are on the authoring line: they build content for their scope but never see the help inbox or an individual student's profile and check-in history. Those are for admins and support responders.
What's the platform-owner role?
It's First Six's own operations/support role, with access across every institution for vendor support. You can't assign it inside your account, and it's held to the same audit trail as everyone else.
Can we create our own roles?
Yes. Institution admins can build custom roles at Settings → Roles: name the role, tick the permissions it should hold (author content, work the help inbox, respond to crisis tickets, view insights, manage students, export evidence, manage audiences, manage settings), and assign people to it. The four built-in roles can't be edited. One permission (managing the team and roles itself) stays with admins and can't be granted to a custom role, so no one can quietly widen their own access. The permissions you tick take effect everywhere at once: the person only sees the parts of the console those permissions allow.
Can I change my own role?
No. To stop you accidentally locking yourself out, you can't change your own role from the Team page; the picker on your own card is disabled. Ask another admin to change it for you. The same protection means the last remaining admin can't be demoted at all.
Who can see the audit log?
Institution admins (and platform owners). Every consequential action is recorded there. See the activity log.
What happens to a leaver's open tickets?
Reassign them before (or as) they leave, with handoff notes, so nothing falls through. The reassignment itself is recorded in the audit trail.
Next steps
Related
The fastest answer is usually one question away.