Student registration and the parent record

At a school, the record that matters is the student, not the customer — the parent is a relationship attached to that student’s card, not the other way round. This article explains why the student card needs to stand on its own, and how the record works in Rotenta.

Why modelling the student as a customer breaks

Stretch a general-purpose CRM to fit a school and the first crack opens at the registration form: the system’s “customer” becomes the parent, and the student is reduced to a note tucked under them. A parent with two children ends up with either two separate customer cards or two students awkwardly split under one. Sibling discounts, moving between classes, transferring to another campus — the most routine operations all trip over this exact point. It’s the thing an education business rejects at the first demo: the student has no identity of their own.

What the student card carries in Rotenta

The student card holds the basics — name, date of birth, student number — alongside up to two parent/guardian links. In cases like a divorced family or a formally appointed guardian, that second contact is part of the card itself, not a note added afterwards. A sibling link works the same way: once a sibling is registered, sibling discounts and family-level reporting build on that link automatically.

The student card sits inside a level → class → branch tree. Which class and branch a student belongs to isn’t a single field — it’s a node in that tree, so moving classes adds a new term rather than overwriting the old one.

Shuttle service, parent contact and health/guidance notes

For students who use the school shuttle, the student card connects to the recurring-shuttle plan; which route and stop they’re on lives on the card. Sensitive fields like a health report or a guidance note sit behind their own permission — only authorised staff see them, not accounting or the shuttle team. That split matches both KVKK’s treatment of special-category data and the everyday need for “not everyone should see everything.”

Example: at a kindergarten, only the class teacher and the administrator can see a student’s allergy note, while someone looking at the same student’s outstanding instalment only sees it from the billing screen — both facts live on the same student card, opened through different permissions.

A family-level view, and what happens after graduation

Once the sibling link is set, administration can see from a single view how many students a family has enrolled, how much they’ve paid in total, and which discounts apply — a different question from looking up each student one at a time. When a student graduates or leaves, the card isn’t deleted, it’s set inactive — the instalment, attendance and exam history stays reachable afterwards as a reference, for instance when a sibling later registers or when a student certificate is requested.

Migrating without double data entry against e-Okul/MEBBİS

Most schools already have their student data sitting in e-Okul or MEBBİS (Turkey’s national school data systems); since there’s no official API, moving that data into a new system goes through the Excel/CSV import wizard. The wizard matches on a field such as student number, so a second import updates the existing record instead of creating a duplicate student.

The teacher’s screen isn’t the administrator’s screen

Even though the student card is a single record, not everyone sees the same fields on it: a class teacher sees attendance and grade entry, administration sees registration and contract details, accounting only reaches the billing screen. That split is defined through Roles, permissions and audit trail, and which field a staff member viewed on which student card lands in the same record. During enrolment season, when temporary staff are brought on, that separation is a practical safeguard against someone accidentally opening a health note.

How student registration works in Rotenta

1. You open a new student card in the Student module and enter the name, date of birth and student number.
2. On the same screen you add the first parent/guardian link, and a second one if it applies.
3. If there’s a sibling on record, you link them — sibling discounts are calculated from that link.
4. You place the student in the level → class → branch tree.
5. If they use the shuttle, you connect the route and stop through the Recurring Shuttle module.
6. You restrict fields like a health report or guidance note so only staff with that specific permission can see them.

The instalment plan and collection connect to the student card through Instalments and promissory notes; for attendance and parent notification, see Attendance tracking and parent notification. For the wider picture, go back to school management software.

To talk through your institution’s class tree and number of branches, get in touch.

Frequently asked questions

How is a second parent handled in a divorced family?

The second parent/guardian is added as a separate link on the student card; communication preferences and information access can be managed separately for each.

Is the sibling discount calculated automatically?

Once the sibling link is set on the card, a discount rule from Scholarships and discounts by rule is applied to the student card.

If a student changes class or branch, is the history lost?

No. Class/branch history is kept term by term, never overwritten.

Who can see the health information?

Only staff with the permission defined specifically for that field — accounting or shuttle staff don’t see it.

Is a student’s record deleted after graduation?

No. The card is set inactive; instalment, attendance and exam history stay reachable as a reference.