Why Classfolio has no parent portal, and is not planning one
James Connolly · · 6 min read
A parent portal was on my early list for Classfolio. It felt like the sort of feature school software was supposed to have: give parents a login, let them see the work and call it transparency. I had started sketching the login flow before I asked the awkward question: which child, exactly, should that adult be allowed to see?
In a classroom, the relationship between teacher and pupil is fairly clear. Parent access is not. Families change, school records can lag behind, and the person asking for access may not be the person the school is allowed to give it to. The school knows that context; Classfolio does not. I could build another role into the software. I could not make the safeguarding judgement safely, and I did not think a classroom tool should try. That was when I realised a parent portal was not just another login. It would change who Classfolio held data about.
Then I found a field already hiding in Classfolio: "preferred parent communication language". A teacher could fill it in and it saved, but nothing in the product ever read it. We had no parent messaging feature and none scheduled. No pupil record contained a value, so I removed it.
Classfolio does not have parent logins, parent dashboards, parent emails or parent notifications. That is a decision, not a gap in the roadmap. Here is the reasoning, because I would rather a school heard it from us than assumed we had not got round to it.
A parent portal is not another screen. It changes who you hold data about.
This is the part that gets underestimated, and I underestimated it too. Adding parents does not mean adding a page. It means:
- A new category of personal data — names, email addresses, and by implication a relationship to a specific child.
- A new set of rights to service: parents would be able to exercise their data-protection rights through the school as controller, and Classfolio would need to help the school respond. Some of those rights, including erasure, depend on the circumstances and lawful basis.
- A new lawful-basis and transparency assessment: the school would need to determine why parent-account data was necessary, identify the appropriate lawful basis and explain the processing clearly to parents and carers.
- A new access-control surface: which children can this account see, who decides that, and what happens when it changes.
That last one is not a technical problem. It is a safeguarding problem wearing a technical costume. Parental responsibility is not always shared, is not always current in a school's records, and is exactly the kind of thing you do not want a small supplier making assumptions about.
Schools already have established parent-communication routes
Every school I have worked in already has a way of talking to parents — a management information system, a payments platform, a messaging app, often all three. Another login would fragment communication and create more administrative work. Adding a fourth would not make a school more transparent. It would make one more password for a parent to lose and one more system for an office to administer.
We are a classroom tool. The value we add is in the lesson and in the pupil's own record of their work. Nothing about that requires us to hold a parent's contact details.
No parent portal does not mean no parent partnership
Parents and carers should receive clear, useful information about learning. Our decision concerns who controls that communication. Classroom evidence often needs context: an unfinished answer, an early assessment or a single confidence rating should not automatically become a parent notification.
Classfolio is designed to help teachers and pupils build meaningful evidence. The school should decide what is shared with families, when it is shared and what explanation accompanies it, using its established communication channels.
The field I deleted, and the two tests it failed
That "preferred parent communication language" field is the cleanest example I have of why this matters, so it is worth being specific about what was wrong with it.
It failed two tests, and both are worth stealing.
It promised a capability that did not exist
A teacher who sets a field reasonably expects something to happen as a result. This one had a hint saying it was for future parent communications. There were no parent communications, and none were planned. Every teacher who filled it in was doing unpaid data entry for a feature that was never coming.
It collected a third party's personal data for no stated purpose
The preference belonged to a parent. We were gathering it through their child's record, without the parent's knowledge, for a purpose we could not name. That is a data-minimisation failure in the design: the interface invited collection of information that was unnecessary for any live function. It was information we could not justify in our data inventory or record of processing activities.
The cheapest audit I know: pick a personal-data field, search the codebase for its name, and see whether anything actually reads it. If nothing does, you are holding data for a reason you cannot state.
No pupil in production had a value stored, so deleting it cost nothing and orphaned nothing. That is the good version of this story. The bad version is the one where you find the same field three years later with forty thousand values in it.
The one exception, and what it still means for privacy
A school can share a Classfolio questionnaire link with parents and carers. Responding does not create a Classfolio account, login or persistent parent profile.
That does not mean the response can never be personal data. A named response may contain a name or email address, and even an anonymous free-text answer could identify its author. The school decides why the questionnaire is being run, what it asks and whether responses should be named or anonymous. Classfolio processes those responses on the school's instructions.
This keeps the data footprint smaller than a permanent parent portal, but it does not remove our data-protection responsibilities.
It also has a real limitation I would rather state than let a school discover: questionnaires are single-language, so a parent questionnaire cannot currently be served in a parent's home language. For a school with a significant EAL community, that may make it the wrong tool for the job.
What this means if you are assessing us
If a parent portal is on your requirements list, we will not meet it, and I would rather tell you that on a public page than in month three of a pilot.
What you get instead is a smaller amount of personal data in one more supplier's hands. Classfolio is a data processor, acting on written instructions from the school, and everything lives in United Kingdom (Google Cloud europe-west2). Classfolio's standing identity records are limited to teachers, school staff and pupils. Parent questionnaires may contain personal data, but they do not create parent accounts or profiles. That list is short on purpose, and every name we do not add to it is a name we cannot lose.
The short version
The best way to protect someone's personal data is not to hold it. A parent portal would have meant holding a new category of person's data, servicing their rights, and making judgements about family circumstances that a classroom tool has no business making.
So there is no parent portal. Not this year, and not when we are bigger — this one is a standing decision, and I would rather be the supplier who explains why than the one who quietly adds it because everyone else has.
Classfolio is a teaching platform built by a teacher. See what it costs, or read why it exists.