Signals, alerts & cases

This is the working end of the wellbeing module: the queue where a request for support lands, the inbox where you confirm you saw an alert, and the plans you make afterwards. It works the same for a corporate HR team, a customer academy, a university department, or a school.

The design principle behind all of it is narrow: nothing here opens because of a score. A person asks, or a rule that has been deliberately installed for your organization fires. Then a human reads it and decides what it means.

What this does

Wellbeing activity produces signals — structured facts like “a check-in was submitted” or “someone asked for support”. Signals feed rules, the only automation in the module. A matching rule can open a case, tell a group of people (an alert), or surface a resource to the person themselves. Cases are triaged by hand; what you decide to do about a pattern is recorded as an action plan.

Three entry points appear in your navigation when you hold the right permission: Support requests (the triage queue), Alerts for me (what you personally owe an answer to), and Action plans.

Before you start

Wellbeing must be switched on for your organization, or the whole section stays out of the navigation.
You need permission to manage wellbeing cases to see the queue at all.
Add at least one support contact in Wellbeing settings. Check-in questions that ask how someone is coping stay switched off until you have one.
Decide who your case managers are first. Escalation looks for a second person holding the case permission; with only one, an unanswered alert has nowhere to go.

How activity becomes a signal

Each signal carries a type, a timestamp, and a payload of scores, bands, ids and counts only — never free text. Each one also carries a per-organization pseudonym for the person it is about, so the rules engine can count “three of these in seven days” without matching on a name.

Signal types cover check-ins invited, submitted or skipped; a Calm Corner item opened; someone asking for support; workplace-conditions responses; feedback submitted or published; cases created, changed or nearing a deadline; action items falling due; and a resource surfaced by a rule.

Signals are written by Lurno’s own services, never by a person. Nobody in your organization can read the signal table — not an owner, not a wellbeing lead — apart from a person reading the rows about themselves, which is what makes a data-subject export possible. Group summaries are computed on the server with the anonymity threshold already applied, rather than by letting anyone query the rows underneath. The same is true of individual check-ins: readable by the person they belong to and by nobody else.

How rules raise alerts

A rule has three parts: the signal types it listens for, a condition, and a list of actions.

Conditions are data, not code — there is no scripting language. A condition is built from all/any groups over three tests: match the signal’s type, compare a value inside it against a literal, or count occurrences in a window (for example, three in seven days). A condition Lurno can’t evaluate is recorded as an error and the rule doesn’t fire; it is never treated as a silent yes or no.

Actions come from a fixed set of five: surface a resource to the person, open a case, notify an audience, propose merging two feedback items for a human to confirm, or nudge an open case’s severity. A rule addresses an audience by permission, never by naming an individual, and only holders of that permission in your organization are reached.

Rules run about once a minute against new signals. Every match and every error is written to an append-only ledger with a snapshot of the rule as it was at the time, so “why did this fire?” survives the rule being edited.

Read the rest of this section as how the engine behaves, not as something you can set up yourself. There is no rule-authoring screen in Lurno, and no rules ship switched on — a rule has to be written into your organization’s rule set before any of this runs. If you have none, cases only ever open because somebody asked, and no alerts are ever raised.

Acknowledge an alert

Alerts are in-app only — never email — and carry a short reference and an urgency, never case content.

Open Alerts for me. Each card shows the urgency, the deadline, and whether it’s overdue.
If the card says the alert never reached you, that’s real: the notification failed or was suppressed, and it was escalated to someone else immediately.
Choose I have seen this.

Only the person the alert was addressed to can acknowledge it — not their manager, not a case manager, not an org owner. The first acknowledgement wins, so tapping twice doesn’t rewrite the time, and a late one is recorded as late rather than hidden. Acknowledging doesn’t undo an escalation that already happened.

If nobody answers, a sweep runs every five minutes and climbs a ladder: routine alerts never auto-escalate, high-urgency alerts climb two levels and urgent ones three, with rungs firing at the deadline, 30 minutes past, and two hours past. Each rung goes to a different holder of the case permission in the same organization; when candidates run out, the record says so and a human has to look.

Work a case

Open Support requests. Switch between Open and All. The queue is sorted oldest first, not by severity — waiting is the failure that ends a wellbeing programme.
Read the row: state, risk tier, days waiting, the request’s own one-line title, and either a name or Anonymous. A name appears only where the person explicitly agreed a lead would see it.
Choose I’ll take this to assign it to yourself and move it to Acknowledged. The button only appears while nobody owns the request; once someone does, the row says Assigned instead.
Choose Mark resolved when it’s done.

A case opens one of two ways: someone asks a lead to get in touch, or a rule opens one. Either way it starts at the lowest risk tier — the product never classifies risk; a person does, after reading.

Those two buttons are the whole of the queue screen today. Underneath, a case record also holds internal notes, updates written for the person, and severity and risk-tier changes, and every one of them is written to the case timeline — but there is no case-detail screen in Lurno yet, so nothing on that list has a place to be typed. Internal notes default to private and are never visible to the person the case is about. Case content never includes check-in history: a lead reading a case doesn’t also see that person’s mood scores, because that would turn a voluntary disclosure into a file.

Response deadlines

Where a case carries a response deadline, Lurno warns its owner an hour before it passes, once only, and writes an internal timeline entry. Resolved and closed cases are never warned about, and a case with no owner produces no warning.

Lurno does not set deadlines automatically today. A case has no deadline unless one is put on it, and cases without one never produce past-deadline warnings.

Action plans

Action plans record what your organization decided to do about what people told it. The Action plans page lists them with their state, and each card shows its provenance — the metric, how many answered, and the threshold results were released at — or says plainly it wasn’t based on a survey.

A plan founded on a survey has its numbers recomputed by Lurno, never taken from the request, and a survey below its anonymity threshold can’t found a plan at all. Plans carry counts only, so there is nothing on a plan card that could identify an individual respondent.

Two things are worth knowing before you plan around this page. There is no screen for creating a plan, and the page’s only control is Add an item, which drops a placeholder first step onto the plan — titles, assignees and due dates are set through the API rather than in Lurno today. And although the underlying rules let somebody assigned an item read the plan and move their own item’s state without holding any wellbeing permission, the page itself is gated on the action-plan permission, so there is currently no route into it for an assignee who doesn’t already manage plans.

Who can see what

Who	What they see
The person who asked	Their own request, its state, and updates written for them. Never internal notes or their risk tier.
Case manager	The triage queue, and the case record behind it — including the timeline, which has no screen yet.
Alert recipient	Their own alerts — a reference, urgency, deadline. No case content.
Action-item assignee	The plan and their item at the data level; no screen reaches it today without the action-plan permission.
Everyone else	Nothing. There is no org-wide view of wellbeing content.

In Reporting & Insights, wellbeing appears as case lifecycle only — open, closed and past-deadline counts, plus severity. Submitter, owner, category, risk tier, title, body and resolution are excluded entirely, the report is empty for anyone who doesn’t already manage cases (or who raised or owns the case themselves), and check-in and mood data isn’t reportable at all.

Every state change, assignment and acknowledgement is written to the audit log as enums and ids — never as note or message text.

Reference

Term	What it is
Signal	A structured fact about wellbeing activity. Scores, bands, ids and counts only.
Rule	Listens for signal types, tests a condition, runs actions from a fixed set.
Alert	An in-app notice to an audience defined by permission.
Acknowledgement	A record that a named recipient saw a specific alert. Only they can make it.
Case	A support request being worked: new, acknowledged, in progress, waiting on the person, resolved, closed.
Risk tier	A human judgement — low, raised, high, priority. Never set automatically, never shown to the person.
`wellbeing.case.manage`	Permission behind the triage queue and case content.
`wellbeing.alert.ack`	Permission behind the alerts inbox. Acknowledging is gated on being the addressee, not on this key.
`wellbeing.action_plan.manage`	Permission behind the Action plans page, creating plans, and defining items.

Troubleshooting

I can’t see Support requests or Alerts for me. Either wellbeing isn’t switched on for your organization — the whole section disappears from the navigation when it’s off — or you don’t hold the wellbeing case or alert permission. Organization administrators hold the case permission by default; other roles need it granted, and a custom role gets nothing automatically. See Roles & permissions.

An alert says it never reached me. The notification was suppressed or failed. Lurno treats that as a delivery failure for high and urgent alerts and escalates immediately rather than waiting out a window nobody is sitting in. Acknowledge it anyway to close your side of the record.

Someone else can’t acknowledge an alert for me. By design — no permission lets one person answer for another. A lead who wants the queue cleared can reassign or escalate instead.

A case shows Anonymous with no name. It wasn’t raised by a person asking — a request for support can only be sent with explicit consent to be named, so those always carry a name. A case showing Anonymous was opened by a rule, which works from a pseudonym and never has an identity to store. There is nothing hidden behind it to reveal.

Alerts stopped arriving. Check somebody in the organization still holds the permission the rule addresses. A rule whose audience permission is held by nobody records a skip rather than sending, and a quiet system looks identical to a healthy one.