Developing a kindergarten portal: where access breaks
A typical picture: the portal is launched, the parent's personal account works, photos from matinees are posted — but actual access to them is granted not by a role in the system, but by a link in the group chat.
Closed group albums remain effectively open. The link is not tied to the parent's account, lives indefinitely and travels further along with the chat history; it cannot be revoked after sending, and no log is kept of who exactly downloaded the photos. After a season, such albums are found in open search.
Access separation for educators in homegrown solutions comes down to one set for everyone: a teacher of one group sees other groups' albums and data, a former employee retains access until a manual password change, and the administrator and educator roles are not separated.
A teacher who maintains documentation also gains rights to the institution's archive — this is no longer an inconvenience, but a class of incidents.
Storage of children's personal data is usually moved outside the controlled perimeter: applications, certificates and medical records sit in spreadsheets on personal accounts, and parental consents — on paper with no link to the database record.
Access to the institution's documents itself is distributed in the same way — as a file via a direct link.
Bottom line: the system formally exists, but only the storefront remains manageable — rights, link lifetimes and the storage perimeter live separately from it.
We look at how this is closed in kindergarten portal development: access is granted by role and group, a link has an expiration and can be revoked, and children's personal data is stored in a single perimeter with an access log.
Implementation effect: publishing, load, manual operations
Group materials used to go through the administrator: collect photos from the teacher's phone, rename, upload, grant rights to each parent.
Now the teacher publishes from the panel — an album of 30–40 photos goes to the closed section in 2–3 minutes, including compression and tagging by access rights.
The administrator's share of manual operations drops from most of the workday to rare exceptions. Notifications about new materials are sent automatically to the group list, and the parent's access opens on first login via invitation. Only non-standard cases remain manual — moving a child to another group, re-issuing access.
The morning peak, when several hundred parents open the feed and albums simultaneously, used to be a point of failure: a single application could not hold the connections, and some parents got an error page instead of photos.
Now the application runs in several instances behind a load balancer, and notification sending goes into a queue — a slow mail gateway no longer blocks page delivery.
Children's albums are a special category of data, so access is built on certified security tools (CryptoPro) and rights separation at the level of individual records, not only at account login.
The class of failures "portal unavailable at peak hour" stopped reproducing: load is distributed, publishing does not depend on the administrator, and notifications arrive without manual mailing.
Comparison of options: ready-made solution, module, service
The fork is simple: a standard ready-made solution for a kindergarten, a personal account module on top of an existing website, or a separate service for the institution.
The difference is not in the set of buttons — it is in how closely your processes match the built-in ones, who is responsible for storing the personal data of children and parents, and how reversible the solution is if it stops fitting.
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made solution for a kindergarten | Parents and educators work according to a standard scenario, quick launch is needed, and there is no in-house support team | Limitations of a standard system: a fixed set of forms and reports, its own rules for closed albums; a non-standard scenario can only be covered by custom development from the vendor |
| Personal account module on top of an existing website | The website is already populated and works, and there are no plans to change the design or address | Accounts inherit the website's template and access rights: the "child — parent — group — methodologist" link and file separation are configured only to a limited extent |
| Separate service for the institution | You need your own role rules, closed albums by group, and data exchange with the kindergarten's record-keeping system | More work at the start: your own infrastructure, a separate personal data perimeter, and integration with the website and record data |
Separately, we check data migration when changing solutions: the list of groups, child cards, consent to personal data processing and album files must be exportable in open formats, without manual re-entry.
If export is available only "through vendor support" — that is the main limitation of the option, and it is visible already at the selection stage.
Work stages: from assessment to handover to operation
A kindergarten portal differs from a regular website: almost all content is children's personal data, and the set of roles changes every year. We start not from the mockup, but from the access model, and check 152-FZ requirements at every step. Below is the sequence of work.
- Assessment of roles and groups. We record roles — parent and second parent, educator, methodologist, head, administrator — and for each, the list of sections and permitted actions. We separately discuss transitions: admission to a group, transfer, graduation, temporary access for a relative.
- Portal data schema. We link the child's card, group, parent account, album and photography consent. The schema sets the rules in advance: when a child is transferred, access moves with them rather than being edited manually by the administrator.
- Setting up closed sections. We check rights on the server side for each record, not by hiding buttons in the browser. An album is delivered only to parents of children in that group, and a direct file link does not work bypassing the portal.
- Load testing. We run peak scenarios: mass parent login in the morning, publishing an album with several hundred photos, sending notifications. We look at response time and behavior under simultaneous requests.
- Handover to operation. We give administrators instructions on granting and revoking access, backup settings and the employee action log, and a procedure for dismissal or change of educator.
What remains with the customer: configuration, schemas, regulations
After the portal launch, everything that ensures its operation remains with the customer — not in chat history and not in the contractor's head.
We transfer the source code, environment configurations and documentation to your account, and register access for the institution itself. Below is exactly what the package includes.
- Source code and configurations: build, environment parameters, database migrations — a copy of the portal can be raised without our involvement.
- Role and rights schema with an access matrix: parent, educator, head, administrator — who sees what and what action they can perform.
- Access policies for closed albums: which group sees what, who publishes, how access is revoked when a child transfers to another kindergarten.
- Portal administrator instructions: creating groups and accounts, publishing albums, resetting access, reviewing the action log.
- Personal data processing procedure: composition of children's and parents' data, retention periods, deletion procedure on request, responsible person within the institution.
- Document package for 152-FZ: consents, privacy policy, notification to the supervisory authority, templates for responses to parent requests.
- One-page memo for educators: how to upload photos and what information must not be posted publicly.
We maintain documentation together with the code: when rights change or a new section appears, the instructions are updated in the same release.
A year later, the portal will not turn out to be "nobody's" — a new administrator or another contractor will figure it out from the transferred schemas.
Case study: removed manual access issuance and phone calls to parents
A kindergarten with 12 groups kept photo reports in a messenger: the administrator manually checked which parents had the right to see an album and wrote to the chat for each new parent.
Part of the workday went to verification, and access outlived a child's withdrawal — hence the disputed situations with photos of other children.
What was changed
The portal was built on 1C-Bitrix with a separate secure file storage. Rights are inherited from role and group: a parent sees only their own album, an educator — only their groups, the head — everything.
Consent to data processing is completed in the account with a timestamp, and every album opening is logged.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Access requests | 30–40 per month, manually via chat | 1–2 per month, the rest — independently in the account |
| Publishing a group album | 1–2 days to verify lists | 15 minutes: uploaded and opened to the required group |
| Errors in granting rights | 6–8 per quarter: another parent in the album, a withdrawn child with access | 0 per quarter — the right is granted by role, not by a person |
| Consent collection | paper forms in a folder | electronic consent with a timestamp |
Upon withdrawal, access is removed by switching the role, not by a message in chat: rollback takes a minute and is confirmed by the log. In the quarter after launch, there was not a single case where a parent from another group saw an album.
What to do if the kindergarten already has a website and cloud drive?
The website and cloud drive already work — the question is not about rewriting them, but about where the boundary lies between the public part and the closed perimeter.
Pages, schedules and documents remain on the website; albums, children's data and communication with parents move into the account, which cannot be accessed via a single link.
From the cloud, we transfer the album structure, group links and the files themselves — by batch export through the storage API.
We rebuild access rights anew: the "anyone with the link" mode is not transferred to the new perimeter; instead, the parent role is rigidly linked to the child and their group.
Integration with the existing website is built on single sign-on: the parent logs in once, the session is shared, and a second login and password are not needed.
The login button and account are embedded into the current design, and page addresses and search positions are preserved.
We separately fix the master system for each data type: the composition of children, groups and employees is maintained in one place, albums live only in the portal, and the website keeps a storefront without copies.
Otherwise, data duplication diverges at the very first edit, and the parent sees an outdated version.
Migration proceeds without stopping operations: the new perimeter is populated in parallel with the cloud, we launch a pilot on one group, verify the completeness of albums and access, then connect the rest.
We switch the old storage to read-only mode and close it after a control period — rollback fits within hours.
Questions on access, data storage and load
We describe rights not as a list of positions, but as an "object × role" matrix: group album, child card, announcement, document export.
An educator sees only their group, a parent — only their child, and publishing a photo requires separate permission, with each such action logged.
Children's data is a sensitive category, so fields are divided by levels: identification, contacts, medical notes.
We store it in a secure perimeter, write access to an immutable log, and set the retention period by policy — when it expires, the record is deleted along with related files.
What if some parents refuse the personal account?
The portal works in two modes. The educator publishes materials in a closed album, and for a parent without an account they are delivered in the usual way — print, notice board, personal message through the educator. The refusal is recorded in the card, and the system no longer sends invitations and reminders.
Will the portal withstand peak days?
Peak is morning and evening, plus days of enrollment in clubs and matinees, when hundreds of parents log in simultaneously.
We serve albums from cache, photos — through separate storage with compressed previews, and heavy tasks such as mass mailing and archive assembly are moved to a queue. We capture the load profile in advance from the logs of a real kindergarten.
Can the portal be hosted on your own servers?
Yes. We deploy it in your perimeter if data must not leave the kindergarten's or management company's infrastructure. Backups run on schedule, restoration is tested on a staging environment, and updates are installed with the ability to roll back to the previous version.
Let's discuss the task: we'll return with an estimate and work plan
For the portal estimate to be based on scope and not guesses, a few inputs are enough to start.
Describe who will use the system and which roles are needed — parent, educator, administrator, methodologist — and which personal account sections are closed and which are visible to everyone.
Separately, it is important how work with consent to personal data processing of children is organized today and who will populate group albums.
- List of roles: what each sees, what they can change, who is denied access.
- Composition of first-version sections: personal account, closed albums, announcements, documents, requests — and what we move to the next stage.
- How consent to personal data processing is currently issued, stored and revoked.
- Who administers the portal and how quickly access is closed when an employee leaves.
- Whether there is an existing website and domain, and where data and backups are planned to be hosted.
- Target launch timeline — for example, by the start of the school season.
Then we review the inputs and come back with a plan: the scope of work by stage, the role and access rights schema, the procedure for working with personal data and closed albums, timelines and points where your decisions are needed.
If some answers are not ready yet — we will clarify some in conversation and fix them in the plan. Describe the task — we will return with an estimate and scope of work.
