Enrollment and handoff to the student system
Turn the signed contract into an enrollment, keep the family forms (medical, transport, meals, authorizations, emergency contact and insurance) under control with validity and yearly renewal, and hand the student off to your student information system with a reconciliation queue that surfaces every difference. Part of the Education vertical, optional and off until an administrator activates it.
The Education screen gains an Enrollment block: this is where an admitted applicant becomes an enrolled student, the family forms stay under control, and the enrollment is handed off to the school student system.
Where the enrollment comes from
The enrollment is created from the signed contract: once every required signer has signed, the system creates that student enrollment for the term. You can also create it from the screen when the case did not go through a contract. Both paths are idempotent: the same person, in the same term and program, never becomes two enrollments, no matter how many times the action is repeated.
An enrollment starts as pending. Activate it when the student starts, record the withdrawal if the family drops out, and complete it at the end of the term. Closed states never go back.
Forms with validity and renewal
Each enrollment carries the forms your school requires. The state of each one is computed when you read it, from the validity dates, so the list is always right even if no background job has run: valid, expiring, expired, missing, not submitted, awaiting approval or rejected.
- Medical: conditions, allergies and medication
- Transport: route, stop and authorized people
- Meals: dietary restrictions
- Authorizations: images, field trips and pickup
- Emergency contact
- School insurance
Renewal is yearly by default and the period is configurable. Renewing erases nothing: it creates a new version and keeps the previous one as the record of what the family declared in that cycle. The "forms needing action" panel lists everything expired, expiring or pending in the term.
Handoff to the student system
The CRM is not your student information system: it does not post grades, does not keep official attendance and does not issue transcripts. What it does is hand the enrollment to the system that owns that data. And one rule is absolute here: the enrollment only shows as created there when that system returns its own student id. An attempt, an outage or a missing connector never counts as "created".
- Queue the enrollment for handoff.
- Export the queue as CSV.
- Load the file into your student system.
- Import the confirmation file back, with a reference column (the code we exported) and external_id (the student id in your system).
When an API connector becomes available for your system, the same flow works without files, with nothing to reconfigure.
Reconciliation queue
Every difference between the CRM and the student system shows up field by field in the reconciliation queue, with the value on both sides, and the owner gets an alert. A difference never quietly disappears: the item stays in the queue until both sides match. A periodic job repeats the comparison and warns when the agreed handoff deadline passes without confirmation.