PowerSchool Enrollment and Kastr: where new-family data should come from
This page exists to talk a district out of something. Registration and enrolment products hold contact details for families before those families exist in the SIS, which makes them a tempting source for a communications roster in August. It is the wrong source, and the four failure modes it produces are all expensive. Sync from the system of record, and handle the gap deliberately.
| District configuration | Submission to SIS record | SIS record to nightly extract | Total gap | Back-to-school risk |
|---|---|---|---|---|
| Continuous approval, daily import | 1–2 days | Same night | 1–3 days | Low |
| Batch approval, twice weekly | 2–5 days | Same night | 3–6 days | Moderate |
| Registrar review queue, one building | 3–10 days | Same night | 4–11 days | Moderate |
| Central office review, August peak | 5–15 days | Same night | 6–16 days | High — families miss the first-day message |
| Document verification required first | Until documents arrive | Same night | Unbounded | High — and invisible unless counted |
| Weekly extract rather than nightly | Any of the above | Up to 7 days | Add a week to every row | High — move to nightly |
Find your own row before August rather than during it. The number that matters is the last column of families still sitting in the queue at 5pm on the day before term starts — those are the families who will not receive the first-day message, and every district has some. Counting them is a ten-minute query and it converts an invisible problem into a list somebody can work.
Why the shortcut fails, in four specific ways
The tempting pipeline is registration form → Kastr, bypassing the SIS, so that new families can be messaged in August. Here is what goes wrong.
- Duplicate identities. A family that registers, withdraws and re-registers — a house move, a change of school choice, a form submitted twice because the first seemed not to save — produces multiple submissions. A naive pipeline creates a person per submission. Three records, three phone numbers, three copies of every message, and a parent who concludes the district cannot count.
- No withdrawal signal. Registration systems record intent to enrol. They do not record that a family changed their mind, moved out of district in July, or never turned up. Those records stay active in your comms roster forever, because nothing downstream ever tells them to stop.
- No authoritative school assignment. Registration captures a requested school. The SIS holds the assigned one. Roster your organisation hierarchy from requests and your records sit under the wrong buildings from day one.
- Two systems of record for the same fact. A parent corrects their mobile number in September, in the SIS, at the front desk. The registration record still holds the old one. Which wins depends on which pipeline ran last, which is a question nobody should have to answer about an emergency contact number.
The correct topology is one line: registration and enrolment forms → SIS of record → Kastr. One direction, one authority per fact. The SIS is the only system that knows a student is actually enrolled, at which building, with which guardians, and — crucially — when they stop being enrolled. The mechanism from the SIS is documented at the PowerSchool SIS page.
Messaging families who are registered but not yet in the extract
The gap is real and the need is real: a family that has registered wants the first-day message, the bus route and the supply list like everyone else. Three workable approaches, in order of preference.
1. Shorten the gap. Usually the cheapest fix and the one nobody tries first. Move approvals from weekly batches to daily during August. Move a weekly extract to nightly — there is no reason for a roster feed to run weekly, and it adds up to seven days to every row in the table above. Push document verification to a parallel track so it does not block SIS record creation where your policy allows. A district that gets its total gap under three days has largely solved the problem without buying anything.
2. Message the queue separately, from the registration system. Whatever product holds the pending registrations can usually email the people in it, and for a handful of August messages that is entirely adequate. It keeps the pending population out of your comms roster, which is the whole point, and it disappears naturally once the SIS record exists.
3. Load a deliberate, dated, temporary set. If you must have those families in Kastr before the SIS has them, do it as an explicit one-off import with the same stable identifier the SIS will use, so that tonight's file matches rather than duplicates. Never as a standing nightly pipeline. Two conditions before you do it: you have confirmed the identifier will match, and you have a date on which you check that every one of those records has been superseded by the SIS feed.
The failure to avoid is option 3 becoming permanent. A temporary August pipeline that nobody turns off is how a district ends up with two sources of truth in November.
What stops a re-registering family becoming a duplicate, and what Kastr does not do
Kastr's protection is structural rather than clever: one person, one identity, many effective-dated roles. A student who registers in June, withdraws in July and re-registers in August is one person with role rows that start and end, provided the SIS gives us the same stable identifier each time. The diff engine matches on that identifier and hashes the record payload with SHA-256 to classify the change; a returning student reads as a change, not as a second human being.
Which is precisely why the source matters. The SIS is the system that reuses the identifier. A registration submission generally does not — each submission is its own object. Feed Kastr from the submissions and you have handed the identity problem to a system that was never designed to solve it.
The same design handles the other case districts trip over: an adult who is a guardian at the elementary school, a guardian at the high school and a substitute teacher is one identity with three effective-dated roles, not three records receiving three copies of a district-wide message.
What Kastr does not do here, plainly. Kastr is not a registration or enrolment product. It collects no forms, no documents, no residency proofs, no consent forms and no signatures. It does not verify addresses, does not run a queue and does not do workflow approval. There is no write-back to PowerSchool of any kind, so a contact correction a guardian gives us stays in Kastr until someone updates the SIS — and tonight's file will overwrite it. There is also no native PowerSchool connector: no plugin, no certificate flow, no partnership. Your district produces an export and a job you own POSTs it.
The three weeks before day one, as a checklist: run the roster nightly rather than weekly from the start of August; count the pending-registration queue every morning and work it down; run a dry run and read the ledger daily rather than weekly during the ramp; pull the list of students with no reachable contact point and hand it to each building office; send a test message to yourself before the first real send; and confirm which audience shape you will use on day one, because Kastr resolves everyone or an explicitly selected set of people, and grade and school targeting do not resolve today.
Questions people actually ask
Can Kastr pull contacts straight from PowerSchool Enrollment?
You could build it and you should not. Registration records intent to enrol, not enrolment: it has no withdrawal signal, no authoritative school assignment, and no stable identity across resubmissions. Sync from the SIS of record instead, where a student is genuinely enrolled, assigned to a building, linked to guardians, and eventually withdrawn. Registration and enrolment forms feed the SIS; the SIS feeds Kastr.
How do I message families who registered but are not in the SIS extract yet?
First, shorten the gap — daily approvals rather than weekly batches in August, and a nightly extract rather than a weekly one, which alone removes up to seven days. Second, message the pending queue from the registration product itself, which keeps them out of your comms roster. Third, only if you must, load a dated one-off set using the identifier the SIS will later use, with a scheduled date to confirm it has been superseded. Never make that a standing pipeline.
What stops a re-registering family becoming a duplicate record?
A stable identifier plus one identity per person. Kastr's diff engine matches on the identifier the SIS supplies and hashes the record payload to classify the change, so a student who registers, withdraws and re-registers is one person with effective-dated role rows rather than three records. That only holds if the source reuses the identifier, which the SIS does and a registration submission generally does not.
Does Kastr collect registration forms or consent forms?
No. Kastr is not an enrolment product: no forms, no documents, no residency verification, no signatures, no approval workflow. It also never writes back to PowerSchool, so any correction a guardian gives us stays in Kastr until someone updates the SIS, and tonight's roster file will overwrite it. Corrections belong upstream.
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.