Wellbeing overview

Wellbeing is an optional module for looking after the people who run your learning programmes, rather than the people taking them. It gives your staff a fifteen-second check-in, a shelf of short practical content, a way to raise a concern or an idea, and a way to ask a named lead to get in touch. It gives whoever leads on wellbeing a queue of those requests, group-level insights, and action plans.

It is deliberately context-agnostic. In a corporate or workforce setting this is employee wellbeing: pulse check-ins, an employee assistance contact, and a view of how workload feels across a team. In a school or university it is staff pastoral care — the same surfaces, pointed at teaching staff and a safeguarding lead. The module assumes neither.

What this does

Wellbeing collects a small amount of self-reported information from staff, under an explicit opt-in. Daily check-in answers become one thing only: a private record the person themselves can read. Separately, workplace-conditions campaigns produce group summaries — and those stay hidden until enough people have answered for nobody to be identifiable.

One rule shapes everything else: no individual check-in answer is readable by anyone else in your organization. Answers are stored against a code derived from the person and the organization, and the database rule on that table matches only the person who wrote the row. No screen in the product opens one person’s check-in — not for their manager, not for a wellbeing lead, not for an org owner.

A name only ever gets attached elsewhere in the module, and only when the person chooses it: on a support request (where they tick a line confirming a lead will see their name and message), and on Voice feedback posted non-anonymously.

Subjects are staff. Two things decide that, and they are not the same thing:

Who is offered a check-in. Anyone whose roles include something other than the learner role or the guardian role. Custom roles you invent count as staff here without anyone maintaining a list.
Who can actually complete one. Permission to complete your own check-ins, which ships on the built-in staff roles — Client Admin, Sub-Org Admin Manager, Instructor, Facilitator, Manager, Mentor and Reviewer. A brand-new custom role does not get it automatically; grant it, or clone a role that already has it. See Roles & permissions.

Learners and guardians are not check-in subjects in this version; a learner inside a targeted group is still not offered one. Learner and instructor are default terms and may be renamed for your organization; see Terminology.

Before you start

You need permission to manage wellbeing settings. By default this travels with permission to update your organization, so org admins have it.
Decide your support contacts first. At least one is required before reminders send, and no check-in question that asks how someone is coping can be served until one exists.
Set your organization’s time zone if you want reminders — the module will not guess an hour. See Organization settings.
To target a group rather than all staff, create it first with at least five members. See Groups.

Turn wellbeing on

Open Wellbeing settings from the Wellbeing section of the sidebar. This entry stays visible to anyone with permission to manage wellbeing settings whether or not the module is on, so switching it off is never a one-way door.
Work down the Setup checklist — four rows: support contacts, audience, cadence, and the switch itself. Support contacts is the only one marked Required.
Add at least one support contact — a name plus a way to reach them, typed as employee assistance, counsellor, safeguarding lead, or helpline. A contact with no reachable detail is refused; it would only look like help.
Choose your cadence and audience. See Check-ins.
Turn on the switch labelled Wellbeing is on for this organisation and save.

Until that switch is on the module records nothing: check-ins, support requests, feedback, and campaign responses are all refused at the server, and every wellbeing entry except Settings disappears from the sidebar.

Lurno platform administrators use the Wellbeing tab on the organization’s record in the platform console instead — the tenant settings page reads your active organization, which platform admins do not have. That tab carries only the switch, labelled Wellbeing is available to this organisation. Cadence, audience, threshold, and support contacts stay with the organization on its own settings page.

What’s in the module

Each area appears only when the module is on and you hold the matching permission. Two deliberate exceptions: My one-to-ones has no permission gate at all (being scheduled into one is what grants access, and the list is simply empty otherwise), and Wellbeing settings stays visible even while the module is off.

Area	What it is	Who sees it
Wellbeing	Your own check-in, plus a streak card	Anyone who can complete their own check-ins
Calm Corner	Short practical content, plus your support contacts	Same
My check-ins	Your own history and trend, 7/30/90 days	Same — only you see yours
My support requests	Requests you sent, and updates written back to you	Same
Voice	Raise a concern, idea, or question — anonymously if allowed	Same
Support requests	The queue of requests people sent, oldest first	Can manage wellbeing cases
Alerts for me	Alerts you personally must acknowledge	Can acknowledge wellbeing alerts
Wellbeing insights	Workplace-conditions campaigns and their group results	Can view wellbeing insights
Action plans	What you decided to do about what people told you	Can manage action plans
My one-to-ones	Conversations you are a participant in	Everyone — the list is empty unless you are in one
Wellbeing settings	Cadence, audience, reminders, anonymity, contacts	Can manage wellbeing settings

The privacy stance

These are enforced in the product, not aspirations.

Pseudonymous storage. Answers are keyed by a code, not a name, and the code is derived per organization. When someone is erased, the identity is dropped from their check-in rows and the code is kept, so group totals stay consistent without anyone being identifiable.
A floor of five. Group summaries stay hidden until at least five people have answered. The floor cannot be lowered — not in the UI, not through the API, not in the database, where a constraint on the column refuses anything below 5. An individual insights campaign can ask for a higher threshold; the settings page shows the org floor read-only, with the reason it does not go down. Below the floor you see nothing, not a smaller number and not an average. Where a chart could still isolate someone, answers held by fewer than three people are merged into “Other answers” rather than dropped, so the hidden count cannot be recovered by subtraction.
Targeting has a floor too. A group audience needs five members; pointing a programme at four named people is itself a disclosure.
Nothing in the Calm Corner is recorded — not who opened what, or when.
Check-in submissions are deliberately not audited, because a row saying “this person checked in at 08:14” would hand every holder of audit permissions a participation log. Settings changes and de-anonymisation are audited. See Audit log.
De-anonymisation is break-glass and granted to nobody by default. An organization that needs it grants it deliberately, to a named role.
Retention runs on a snapshot. Each row stamps the policy in force when written, then is pseudonymised and later deleted on that snapshot, so a later policy change cannot retroactively destroy or resurrect anything. People can also ask for their answers to be deleted; see Offboarding & data requests.

Reporting follows the same rule: the Wellbeing caseload report shows case lifecycle counts only — never a subject, category, mood, or case content. See Reporting & Insights.

Reference

Term	What it is
Check-in	A short periodic self-report: two required questions plus an optional note
Pseudonym	The code answers are stored under instead of a name
Anonymity threshold	Minimum answers before a summary is shown. Floor of 5, raisable per campaign, never lowerable
Support contact	Someone staff can turn to. Required before mental-health questions or reminders
Audience	Who is offered check-ins: everyone on staff, or one group of at least five
Case	A support request being worked by a wellbeing lead
Signal	An internal record that something happened — never carrying answers

Troubleshooting

The Wellbeing section is missing entirely. Either the module is off for this organization, or you hold no wellbeing permission. If you can manage wellbeing settings you will still see Wellbeing settings while the module is off — that entry is deliberately never hidden, so the switch stays reachable.

I turned on Wellbeing under Module Access and nothing changed. That toggle writes a packaging flag nothing in this module reads. The switch that matters is the one in Wellbeing settings, labelled Wellbeing is on for this organisation.

A sub-organization can’t see wellbeing though the parent has it. There is no inheritance. Open that sub-organization’s own Wellbeing settings and switch it on separately.

Staff say they never see a check-in. Check the audience. Under a group audience only members holding a staff role are offered one — and if the group has fewer than five members, nobody is. If it is one team on a custom role, check that the role carries permission to complete your own check-ins; a custom role built from scratch does not get it by default.

Nothing is recorded even though people say they answered. Confirm the module switch is on. Every wellbeing write path refuses when it is off, including support requests, feedback, and campaign responses.