تخطَّ إلى المحتوى
كل المقالات
المدونة

Guardian access without oversharing

Families want visibility, learners deserve proportion, and the school needs one answer it can defend. Why the data category is the unit of consent.

The Lurno teamAugmentalقراءة 11 دقيقة

لم تُترجَم هذه المقالة بعد — تُعرض النسخة الإنجليزية.

A parent asking to see their child's learning data is asking a question most systems answer in the wrong unit. They decide per person: this adult may see this learner, or may not. What families, learners and safeguarding staff need is a decision per kind of data — results separately from behaviour, the timetable separately from the medical form, one parent granted a narrower set than the other after a separation. Once the unit of consent is the data category rather than the person, most awkward cases in a school stop being exceptions.

The all-or-nothing switch fails on ordinary cases, not exotic ones. A father who should see attendance and nothing about the counselling referral. A sixth-former happy for her parents to see whether she is turning up, and not what her essays came back with. An adult who is legal guardian to one child in a household and step-parent to the other.

Three parties, three claims, all of them fair

The family's claim is easy to state. A parent is accountable for a child they cannot observe for six hours a day, and asking someone to answer for an outcome they may not see is a trap rather than a policy. Half the questions asked at a parents' evening could have been answered a month earlier.

The learner's claim is about proportion rather than secrecy. A twelve-year-old and a seventeen-year-old are not in the same position, and neither is a fifteen-year-old halfway through a conversation with a school counsellor. Learners censor themselves when they believe a record is read at home, which turns pastoral notes into the thing nobody writes down.

The school's claim is the one forgotten in the design, and it decides whether the other two survive. A school has to give one answer, apply it identically to every family on the roll, and defend it a year later to a solicitor, an inspector or a safeguarding review. An answer living in the judgement of whoever is on the front desk is not one answer.

Should parents be able to see everything about their child's school record?

No, and "nothing" is equally wrong. The defensible position is that a parent sees the categories their verified relationship grants — usually progress, results and timetable — while categories carrying a different duty of care, such as pastoral and safeguarding notes, go through a named member of staff rather than a portal. Where you draw the line matters less than that it is drawn once, in writing, and enforced by the software rather than by whoever answers the phone.

Data category scoping

Access granted per relationship and per kind of data, rather than per person. Instead of one switch saying an adult may or may not see a learner, the grant is a set of rows: this guardian, over this learner, in this organisation, for attendance and schedule — not for behaviour, medical or financial. Every read asks whether the reader holds the category the data belongs to. Two guardians of the same child can hold different sets, which after a separation is the ordinary case.

A workable registry is short and boring. Academic — results and the work behind them. Attendance — presence, lateness, absence. Schedule — the timetable and what is coming. Behavioural — incidents and disciplinary notes. Medical — health forms, allergies, emergency contacts. Financial — invoices and fees. Communications — messages between school and home. The value is not the list. It is that one row can be decided without moving the other six.

Two rules keep a registry honest. A category somebody has not been granted should be absent from the interface, not shown and disabled: a greyed-out Behaviour tab tells a parent that behaviour records exist and somebody withheld them, which is a conversation the school did not choose to start. And never offer a category with nothing behind it — a tick box granting access to a screen nobody built tells an administrator they have done something they have not.

Lurno

A guardian holds attendance and schedule, so the portal has two sections. The other five are not options that were refused — they are not part of what this relationship returns.

Not this

A guardian is "linked" to a learner, sees every screen the product has, and the data policy exists as a paragraph in a handbook the software has never read.

What changes as the learner gets older

Access should narrow as a learner grows, and the trigger is a birthday less often than people expect. Under FERPA, rights over a US student's education records pass from the parent to the student at 18 or on entering post-secondary education — a hard cut-off. The Information Commissioner's Office takes a different route: in Scotland a child of 12 is presumed capable of exercising their own data rights, while in England, Wales and Northern Ireland it is a test of the child's understanding rather than a fixed age. One hard-coded number will be wrong somewhere.

The pattern that survives both: below your threshold, a guardianship is created and verified by the institution; above it, the learner is the grantor. Same relationship, different person authorising it. An adult learner chooses the categories and can set an expiry — a parent given sight of attendance for one term while things are difficult, lapsing on its own rather than needing a second awkward conversation.

Two details are worth settling before the first grant. Store the exact wording somebody agreed to, verbatim, at the moment they agreed: rewording the consent screen next year must not retroactively change what everybody already consented to, and the only way to be sure is to keep the sentence rather than a version number pointing at one since edited. Then decide whether ending a relationship notifies the other party. Both answers are defensible; an undocumented one is not, because the case where it matters is a learner quietly removing a parent's access.

At what age should a student control their own school data?

It depends on the jurisdiction, so run two mechanisms rather than one. FERPA transfers rights to the student at 18 or on entry to post-secondary education. The ICO treats 12 as the presumed age of capacity in Scotland and applies a competence test elsewhere in the UK. Practically: institution-verified guardianship below your threshold, learner-granted access above it, with identical category scoping on both. Moving the threshold is then a policy change rather than a rebuild.

A guardian and a teacher must see the same number

The fastest way to lose a parent's trust is not showing them too little. It is showing them a completion figure that does not match the one the form tutor is quoting for the same child in the same week. Both people defend the number in front of them, the meeting becomes an argument about software, and every figure the school publishes afterwards carries a silent asterisk.

This happens for a dull reason. Parent portals are usually built later, often by a different team, as a separate read of the same tables — and separate reads drift. One counts a module complete when the last lesson is opened; the other waits until the final assessment has been marked, a fortnight later. Neither is wrong. They answer different questions under the same word.

The fix sits upstream of the portal. Every published figure needs one definition, one owner and one query behind it, and the guardian view has to be a scoped read of that query rather than a reimplementation of it. Scoped, not separate: the same metric, filtered to one learner whose identity is validated on the server rather than trusted from the browser. A parent and a form tutor disagreeing is normal. Disagreeing about arithmetic is not.

Why does the parent portal show a different number from the teacher's dashboard?

Almost always because the two views compute the same word differently, not because one has stale data. Completion, attendance and "active this week" are the usual three. Ask for the exact rule behind each: which event starts the count, which ends it, and what happens to a learner who left mid-programme. If the portal was built as a second query over the same tables, assume it has drifted, and that nobody noticed until a parent read both numbers aloud.

Authorise on the relationship, not the role

Most permission systems answer "may this person read learner data?" with a role. A role is the right tool for deciding which navigation somebody gets and the wrong tool for deciding whose child they can see, because a role is a category of person and a guardianship is a fact about two specific people. Grant a guardian role by mistake — a mistyped invitation, a bulk import with a column shifted by one, a leaver who kept their account — and the system has handed a stranger a cohort.

Authorising on the relationship inverts that failure. The permission is a verified link between two named people inside one organisation, re-checked on every read: does it exist, was it verified, is it still live, has it not expired, and does it carry the category this data belongs to. The role then decides only the shape of the interface — somebody holding a guardian role and no relationship signs in to a portal with nobody in it.

That is how the guardian portal in Lurno works, and the check is a database function rather than an application one — is_active_guardian_scoped(guardian, learner, organisation, category) — evaluated by the row-level security policies that return a learner's data. That rule is enforced by the platform itself, which matters for an unglamorous reason: an export written next year by somebody who never read this article still cannot return a row to a guardian without the category.

Role check — what most systems do
  role(user) == "guardian"
  → every learner the role's scope can reach

Relationship check — re-run on every read
  is_active_guardian_scoped(guardian, learner, organisation, category)
  → the link exists and a named person verified it
  → it has not been revoked and has not expired
  → it carries the category this data belongs to
  → both people sit in this organisation

  A role granted by mistake exposes nobody.
  A filter forgotten in a new export returns nothing.

The rest of the design is procedural. A request to be somebody's guardian is a claim about a family, and months later somebody has to say who accepted it, when, against which custody document, and what they narrowed it to. That means a queue, a named reviewer, and the ability to reduce the categories at the moment of approval — shared custody settled at verification rather than in a support ticket in March. Raising a request and approving one should be different permissions.

Where this sits today, plainly: Lurno ships the registry of seven categories, and two — academic and schedule — have a portal surface a guardian can read. The other five are real rows with real database predicates behind them, so adding one is a screen rather than a schema change, but plan around what is grantable now. The guardian's progress figures read the same certified metrics the staff and learner views read, which is what stops the two-numbers argument; that layer is on reporting and analytics.

One boundary matters to groups. A guardianship belongs to the organisation it was verified in, so a parent verified at one school gets no view into a sibling school, even when the same child later enrols there — that is a second relationship, verified again. At the scale of a K-12 publisher running 114 schools on one platform, that is the difference between a data policy and a data incident. The wider structure is in Lurno for schools.

Can two parents have different levels of access to the same child?

Yes, if access is granted per relationship rather than per learner. Each parent's guardianship carries its own categories, so one can hold academic and schedule while the other holds academic only, and either can be narrowed later without tearing the relationship down. Systems that attach access to the learner — a single "parent portal enabled" flag on the pupil record — cannot express this at all, which is why schools running them handle separated families over email.

Writing the policy before you switch the portal on

  1. Write the category list on paper before anyone configures anything. Against each, name the member of staff who owns the decision to grant it.
  2. Decide the age or capacity test at which the learner becomes the grantor, and write down which law you are following. Two countries means two answers; check the system holds both.
  3. Decide what happens to a category with no screen behind it. The safe answer is that it cannot be granted.
  4. Decide whether revoking a relationship notifies the other party, and put that answer where the person clicking can read it.
  5. Check that ending a relationship takes effect on the next read, not the next sign-in. Anything baked into a session token stays live until that person signs out.
  6. Agree what a guardian sees after the learner leaves. Most policies are silent, and silence resolves to everything, forever.
  7. Ask the vendor to show you two guardians of one child holding different categories, then take one away and watch the section disappear.

The short version

Visibility and proportion are not opposing goals. They are the same decision taken at a finer grain. Make the data category the unit of consent, attach the grant to a verified relationship between two named people rather than a role, let the learner become the grantor as they get older, and make sure the number a parent reads is the number the teacher reads.