Student information system (SIS)
A student information system is the district's system of record for enrolment, scheduling, attendance, grades and the people attached to each student. Nearly everything else in the stack is downstream of it, including whatever sends messages to families.
| Data class | Should be authoritative | Commonly ends up authoritative | Failure when it is wrong |
|---|---|---|---|
| Enrolment status | SIS | A saved recipient list in the comms platform | Withdrawn students' families keep getting messages for months |
| Guardian relationship and custody | SIS | Whoever typed it at the front desk in August | Notices reach a non-custodial adult; a real legal exposure |
| Guardian phone and email | SIS, with a defined write-back path | Both, independently | Two versions of the truth and no rule for which wins |
| Preferred home language | SIS | Nobody — it is inferred or blank | Everything goes out in English by default |
| Section and course membership | SIS (or the LMS in some districts) | Teacher-built groups | Class audiences drift out of date within weeks |
| Message consent and opt-out state | Comms platform and the carrier | The SIS, occasionally | A nightly sync silently overwrites an opt-out |
| Staff login identity | The identity provider | The SIS | Departed staff keep working accounts |
What the SIS owns, and what it does not
The scope of an SIS is administrative rather than instructional. It holds the official record: who is enrolled, in which school, in which sections, with what attendance and what grades, and which adults are attached to each student in which capacity. State reporting is generated from it, and in most districts the funding claim is too.
The confusion is almost always with the learning management system. The LMS is where instruction happens — assignments, submissions, course content, gradebook entry. The SIS is where the official transcript ends up. Districts run both, they exchange data, and the boundary between them is a policy decision rather than a technical one.
The major US K-12 systems each speak a different interoperability shape, which is what actually determines how hard an integration is:
| System | Typical export shapes | Practical note for a comms integration |
|---|---|---|
| PowerSchool SIS | OneRoster, Ed-Fi, plugin/PowerQuery, scheduled CSV | Guardian contact coverage depends heavily on how the district configured contacts |
| Infinite Campus | OneRoster, Ed-Fi, vendor API, scheduled extract | Rich guardian and relationship model when districts use it fully |
| Skyward | OneRoster, Ed-Fi, scheduled extract | Extract scheduling is usually the constraint, not the data model |
| Aeries | REST API, OneRoster, CSV | Common in California; contact ranking is well modelled |
| Synergy | OneRoster, Ed-Fi, vendor API | Often paired with a statewide Ed-Fi deployment |
| Focus | OneRoster, CSV, vendor API | Varies more by installation than the others |
Support presence is not support quality. Ask which version, which delivery mode, and specifically which guardian fields come across — that last one is where communications projects actually stall.
The contact fields a messaging platform genuinely needs
A communications platform needs a narrow slice of the SIS, and it needs that slice to be right. In rough order of how often each field is wrong in practice:
- Preferred language, per guardian. Not per student, and not per household. Two guardians on one student frequently read different languages. This field is blank far more often than districts expect, and blank almost always resolves to English.
- Contact rank or priority. Which adult is contacted first, and for which categories. Many SIS installations model this properly and many districts never populate it.
- Relationship and custody flags. A grandparent listed as an emergency contact is not automatically a recipient of academic notices. Getting this wrong is the failure mode with legal consequences.
- Phone type. Mobile versus landline determines whether SMS is even possible. A landline in the mobile column produces a permanent, silent failure for that family.
- Enrolment effective dates. Not just a status flag — a start and end date, so a system can tell that a student left in October rather than simply stopped appearing in a file.
Everything a comms platform can do for a family is bounded by these five fields. A platform with excellent delivery infrastructure and a blank language column is an English-only platform.
When the export breaks, and where Kastr actually sits
The dangerous SIS failure is not downtime. It is an export that finishes, parses, and is wrong — a truncated file, a mid-year school-code change, or an ID scheme that quietly reuses identifiers. Every downstream system treats a valid file as truth, so a partial export reads as a mass withdrawal. That is covered in detail on roster sync.
Where we stand, plainly. Kastr has no native connector to PowerSchool, Infinite Campus, Skyward, Aeries or Synergy. Roster data reaches us three ways: a district or its rostering intermediary POSTs to our public /api/v1/roster/sync endpoint, or drops a OneRoster-shaped CSV, or drives it from our MIT-licensed CLI. If a vendor shows you a logo grid, ask what the connector actually does — several in this category are a documented file format with a partner badge on top.
The compensating control is what happens on ingest. Our roster diff engine hashes each incoming payload with SHA-256, classifies every record as add, change, unchanged or withdraw, and aborts the entire run if more than half of active records would be withdrawn. The run is recorded as aborted_guardrail rather than partially applied. That is the specific defence against the truncated-export incident, and it is the thing worth asking every vendor about.
One more honest note, because it matters more than the ingest story: removing a student from the roster only stops messages if something reads that status at send time. In Kastr today, audience resolution does not yet filter on per-person suppression state; the guardrail catches the mass-withdrawal case, and the send-time check is a defect we are closing rather than a feature we are advertising.
Questions people actually ask
What is the difference between an SIS and an LMS?
The SIS is the administrative system of record — enrolment, attendance, official grades, guardians, state reporting. The LMS is where teaching happens — assignments, content, submissions. Grades usually flow from the LMS into the SIS. A communications platform should roster from the SIS, because that is where enrolment status and guardian relationships are authoritative.
Which system should own parent phone numbers?
The SIS, with one defined write-back path from wherever families update their own details. The failure to avoid is two systems both accepting edits with no rule for precedence, because the next nightly sync then silently reverts whichever one a parent used most recently.
Does a communications platform need to write back to the SIS?
Usually not, and the smaller integration is safer. The exceptions districts do want are corrected contact details and language preference. Treat write-back as a separate, explicitly scoped decision rather than a side effect of rostering.
What happens to messaging when the SIS export breaks?
It depends entirely on what the downstream platform does with a short file. A naive sync interprets missing records as withdrawals and can suppress messaging to thousands of families overnight, with every individual step reporting success. Ask what happens when tonight's file has half the records of last night's; the right answer is that the sync refuses to run.
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.