Skip to content

Parent portal

/parent. Needs portal.parent.

Parents sign in and see each of their linked children.

Per child:

Devices Assigned to them
Loans Currently out
Repairs And their status
Purchases With dates, amounts and the product’s photo or icon
Assistance requests And their status
Total repair costs Only if the school chooses to show costs
Charges Approved and later damage charges

Whether costs are visible is a configuration choice, and schools go both ways.

Showing them works where families are expected to contribute and transparency avoids arguments.

Hiding them works where repairs are covered centrally and a number on a screen would prompt questions with no useful answer.

Charges differ from costs. A charge is what a family is being asked to pay, and only approved and later charges are shown. A proposal stays internal. See damage charges.

Single sign-on is the right answer in production. See SSO, where the parent audience is a separate switch.

A sign-in link. A parent asks for a link and one is emailed to them. The parent.login message carries it and cannot be switched off, because it is the mechanism.

Username entry proves nothing on its own, so it is refused by default in production. It exists as an opt-in convenience for demonstrations, controlled by PORTAL_USERNAME_ENTRY.

Your student information system. Plugboard does not maintain family relationships; it reads them.

So a parent seeing the wrong children, or none, is a data problem in the SIS rather than a configuration problem here. Check there first.

Most schools mention it in the start-of-year ICT letter, and again when a repair is lodged.

It reduces “what has happened to my child’s laptop” traffic, which at a school with a device programme is a genuine volume of email.

Everything here is read-only. A parent cannot lodge a repair, cancel one, or change anything.

If a parent lodges a repair for a device they cannot hand over, somebody has to chase it.