How your account is linked to your child

Everything the parent portal shows you depends on one question PTRS asks on every single request: which guardian record is this person?

That answer has to come from somewhere, because signing in and having a guardian record on file are two separate things in two separate systems. PTRS has three different ways of connecting them. They do not agree with each other, and none of them can be set up through the product.

The three mechanisms

1. The link the server actually checks

This is the one that matters. It is a single field on the guardian record, and two things read it.

Signing in looks for a guardian whose stored sign-in id matches yours, and hands your device that guardian's own id. Every single request after that re-reads the same field and compares it with your sign-in again before letting the request through. If it is blank, or belongs to another organisation, or simply does not match, the request is refused with the same message every time, deliberately, so the message itself can never be used to guess a valid id.

That part is a genuinely careful design, and it is the reason a guardian cannot reach another family's child by editing a web address.

Nothing in PTRS ever sets that field. A guardian added through the Members module starts with it blank, and it stays blank: there is no guardian-facing sign-up screen, no invitation of any kind, and no import path that fills it in. A guardian created through PTRS itself can never be recognised the next time they try to sign in.

2. The link the live connection checks

The real-time connection behind the portal does something different: it matches an account by email address instead of by the field above. A guardian can satisfy one check and fail the other, or the reverse. Since nothing is ever actually sent over that connection, this mismatch has no visible effect today. See the hub section of the reference page.

3. The link that was never built

The guardian record also carries a second field clearly meant for this exact purpose, with its own note explaining what it is for. Nothing in PTRS ever reads it or writes to it. It is the third model for the same relationship, and the only one whose own name says plainly what it was meant to do.

Why even a demonstration copy of PTRS does not work either

A copy of PTRS built to demonstrate the product is given one sample guardian meant to sign in successfully during automated testing. Even that one does not work, because the two halves of the link were given different values when the sample data was written.

Record	Field	Value
The sample guardian	The sign-in id the server checks	A fixed placeholder value
The sign-in service's matching test account	Its own id	The same fixed placeholder value, matching correctly
The account actually used to sign that guardian in	Its sign-in id	A different placeholder entirely, not matching

Signing in looks up the account by that last field first, finds nothing, and refuses the sign-in before it ever reaches the guardian lookup below it. So the request for your account details fails, no guardian id ever reaches your device, and every screen's request is switched off before it is sent. Nothing is ever sent to ask.

A real, installed copy of PTRS does not even carry this sample guardian: that sample data is only ever given to a copy of PTRS built for demonstration purposes, never to one actually running for an organisation.

What a guardian sees as a result

Not an error. The screens show their ordinary empty states: no children linked, no messages, no pending forms, no attendance data.

A guardian whose account was never linked and a guardian whose child had a perfectly quiet week see the exact same screen. Nothing tells them apart.

The one case that looks different, and is not

An organisation administrator or a super admin can open a parent web address, because PTRS itself lets all three roles through even though the server accepts a guardian account alone.

Signing in only resolves a guardian id for an account holding the guardian role specifically, so an administrator's requests are switched off too. They see exactly the same empty screens an unlinked guardian sees, rather than a message explaining they are not meant to be there, which makes the real cause harder to spot, not easier.

What would have to change

For completeness, and because this page is the only place the answer exists: a working link needs something that actually sets the field the server checks, whenever a guardian's account is created, plus an account whose own sign-in id genuinely matches the guardian's real one. The identity service already has the pieces needed to create that match; it is simply never asked to. None of that exists today, and this page does not propose building it. It records what is actually there.