Roster sync
Roster sync is the recurring process that moves people and enrolment data from a district's system of record into another application and keeps it current. It is unglamorous, it is where most K-12 implementations actually fail, and almost nobody writes about how it fails.
| Model | Latency | Staff cost | Blast radius of a bad run |
|---|---|---|---|
| Manual CSV upload | Whenever someone remembers | High and recurring | Contained — a human sees the file first |
| SFTP drop, scheduled | Nightly | Low once built | Large — truncation is silent and unattended |
| Nightly full replace | Nightly | Low | Largest — absence from the file means deletion |
| Delta / incremental | Nightly or hourly | Low, higher to build | Smaller — only asserted changes apply |
| Live API push | Minutes | Lowest ongoing, highest to integrate | Small per event, but a bad loop repeats fast |
Full sync versus delta, precisely
A full sync sends the complete current population every run. The receiving system compares the file with what it holds and reconciles the difference — which means absence from the file is an instruction. A student not in tonight's file is understood to have left.
A delta sync sends only what changed since the last run, and every change is explicit: this person was added, this one's phone number changed, this one withdrew. Absence carries no meaning. That single property is why deltas are safer, and it is also why they are harder: the source system has to know reliably what changed, which many SIS extracts cannot tell you.
Most districts end up with a hybrid, and it is the sensible design: a nightly full file, diffed on receipt into an internal delta, with guardrails on the size of the resulting change set. Kastr works this way. Each incoming payload is hashed with SHA-256, every record is classified as add, change, unchanged or withdraw, and the classification is what gets applied — not the file.
The five ways a roster sync goes wrong
| Failure | What it looks like | Control |
|---|---|---|
| Truncated export | Valid CSV, parses cleanly, contains 40% of students | A withdraw threshold that aborts the run instead of applying it |
| Encoding change | Accented names arrive mangled; matching breaks; duplicates appear | Explicit encoding assertion, and a diff that flags a spike in name changes |
| Identifier reuse | A retired student ID is issued to a new student | Match on a stable key plus a birth-date or enrolment-window check, never on name |
| Mid-year school-code change | A school is renumbered; every student appears to move | Treat organisation changes as a separate, reviewed migration |
| Duplicate guardian | The same adult across three students, three times | Dedupe on normalised E.164 phone and lower-cased email before load |
The first one is the incident that ends careers. A nightly job fails halfway, the file that lands is well-formed, and a naive full-replace sync concludes that most of the district has withdrawn. Depending on what withdrawal triggers downstream, thousands of families stop receiving messages overnight and every log line says success.
The one question worth asking every vendor, including us. "What happens if tonight's file has half the records it had last night?" Kastr aborts the sync and records it as aborted_guardrail when a run would withdraw more than half of active records. Overriding that is a deliberate act, not a retry. A vendor whose answer is "we'd apply it and you could re-upload" is describing a data-loss event as a workflow.
Timing, guardians, and what withdrawal should mean
Sync timing is an operational choice that looks technical. If the nightly job finishes at 07:40 and attendance clerks start at 07:30, then for ten minutes each morning the platform holds yesterday's enrolment. Ten minutes is nothing until it is a snow-day send, or an attendance notice fired against a student who transferred in that morning. Finish the run by 05:00, alert on runs that do not, and make the last successful sync time visible to the people who rely on it.
Guardians deserve a specific mention because rostering standards treat them as second-class. Student and staff records are handled well by every intermediary; guardian relationship, contact rank, phone type and preferred language are the fields that arrive thin or blank. Confirm them field by field before an implementation starts rather than discovering them at go-live.
Finally, the question underneath all of this: what does a withdrawal actually do? If it sets a status field that nothing reads at send time, families keep receiving notices about a child who left in October. We will be direct about our own position — Kastr's roster layer classifies and records withdrawals correctly, and our audience resolution does not yet filter on per-person suppression state at send time. That is a defect on our list, not a capability, and we would rather you heard it here than found it in a demo.
Questions people actually ask
What is the difference between a full sync and a delta sync?
A full sync sends the entire population each run, so absence from the file means withdrawal. A delta sync sends only explicit changes, so absence means nothing. Deltas are safer; full files are more common because most SIS extracts cannot reliably report what changed. Diffing a full file into an internal delta on receipt gets most of the benefit.
How often should a district's roster sync run?
Nightly is the norm and is sufficient for almost everything. What matters more than frequency is that the run completes before staff start work, that a failed or skipped run raises an alert to a named person, and that the last successful sync time is visible in the product.
What happens if the nightly roster file is truncated?
In a naive full-replace sync, missing records are read as withdrawals and can suppress messaging to most of a district silently. The defence is a threshold on the withdraw count that aborts the whole run. Kastr aborts above 50% of active records and records the attempt rather than applying it.
Does roster sync include parent and guardian records?
Sometimes, and less completely than districts expect. Rostering standards centre on students, staff and sections. Guardian relationship, contact rank, phone type and preferred language are optional or configuration-dependent nearly everywhere, and they are exactly the fields a communications platform cannot work without.
One price. Every feature. Locked for three years.
$3.50 per student per year under 5,000 students. No tiers, no add-on modules, no per-message fees. Published on the site because you should not have to book a call to learn a price.