Skip to content
Open the app

Student feature toggles

Settings is where you shape what students can do and where a few institution-wide controls live. The most-used control is the student feature toggle. The main thing to hold in mind is reach: these toggles apply to your whole institution, so a change lands for every cohort at once.

Turning features on and off

In Settings → Student features you can enable or disable each student-facing surface: wellbeing (check-ins), the workspace, timetable, events, the campus map, resources (quick links), saved items, and help. Toggles apply to every cohort in the institution at once. Turning a surface off removes it for all intakes together, and turning it back on restores it everywhere. There is no per-cohort feature set, so plan a change as something every cohort will feel at the same time.

Off means gone, not greyed out

When you disable a feature, it is hidden server-side, not just visually masked. The navigation link disappears and the content never renders for students. There is no half-on state a curious student could poke at.

The server-side part matters more than it sounds. A feature that is only hidden in the interface can often still be reached by someone determined. Hiding it server-side means a disabled feature genuinely does not exist for your students, which is the behaviour you want when a toggle is the line between a student seeing something and not.

Disabling help is not the same as removing support

Help is one of the toggles, but think carefully before turning it off. It is the surface students reach for when a week goes hard, and it can be switched off only by your own admins; First Six never switches it off remotely. If your institution runs without it, make sure students have another clear route to support.

Brand

Your institution's brand (logo, accent colour, fonts, email domains, sign-in method, and the crisis copy and signals) is also set at the institution level, so it stays consistent everywhere a student sees First Six. It is read once when a session starts.

The reason crisis copy and signals live here is that they must not vary between intakes. The phrases that detect a crisis and the support copy a student is shown are the same for every cohort, so they cannot be weakened for one group of students. Because brand is read once at session start, a change takes effect for a student on their next session, not mid-session.

Audience tags and staff scope

Audience tags are the campus, program, and role labels you attach to content for targeting: they decide who a briefing or resource reaches. They do not define staff scope. Scope, the slice of students a staff member works with, is set per staff member on the Team page, by degree, campus, or cohort.

The one place tags and scope interact: a staff member can edit a colleague's content when its audience tags overlap their scope. Creating content is not tag-restricted.

Two systems, one overlap

Tags decide who content reaches; scope decides which students a staff member works with, and it is set on the Team page. The overlap only matters for editing: a colleague's content is editable when its audience tags overlap your scope.

Troubleshooting

Turning off Help or Wellbeing asks me to confirm first

Deliberate friction, only on the two toggles with a real student-facing consequence. Turning Help off removes the student's route to staff through the app (anyone who tries anyway is shown emergency contacts instead), and turning Wellbeing off also removes the weekly check-in card from their home page. The confirm is the console making sure that consequence is chosen, not clicked past.

A student says they can still see a feature I turned off

The gate is checked server-side on every page they load, so the feature disappears on their next navigation, not mid-page. If they still see it after loading a fresh page, check you are both talking about the same institution login rather than a demo persona, and that the toggle actually saved (it shows its current state on the Settings page).

The toggle refuses with not authorised

Changing student features is gated to admins (the manage settings permission), enforced in the database rather than just hidden in the interface. If you run the inbox or author content but cannot flip features, that is the roles model working; ask an institution admin.

Common questions

If I turn a feature off, can a curious student still reach it?

No. Disabling a feature hides it server-side, so the navigation link disappears and the content never renders for students. There is no half-on state left for someone to poke at.

Can crisis copy or signals differ between cohorts?

No. They live at the institution level, alongside brand, so they stay consistent for every cohort and cannot be weakened for one group of students. Your institution can add crisis signals on top of the default floor, but that applies institution-wide.

A colleague cannot edit content they think they should. Where do I look?

Two places. Their scope on the Team page, and the content's audience tags: a staff member can edit a colleague's content when its tags overlap their scope. Creating new content is not tag-restricted, so this only comes up when editing someone else's work.

Next steps

Was this helpful?
Need more help?

The fastest answer is usually one question away.

Contact us
Edit this page on GitHub