How to sync PowerSchool eSchoolPlus with Kastr
eSchoolPlus is a mature system with a long memory, which is both why it exports well and why its summer rollover destroys naive nightly jobs. There is no connector and no partnership. There is a scheduled extract, a POST, a contact-priority translation you should do deliberately, and a calendar you should mark before August.
| Period | What is happening in the SIS | Nightly POST | What you do instead |
|---|---|---|---|
| September – May | Steady state; ordinary adds, changes and withdrawals | Safe, unattended | Monitor the run counts weekly |
| Late May – mid June | Year-end close-out; graduating cohort processed in bulk | Watch closely | Check every run's counts. A 20–30% withdrawal night is legitimate and passes the guardrail |
| Mid June – mid July | Rollover: next-year registration, building reassignment, calendar build | Pause it | Manual runs only, counts checked before each POST. This is where mass-withdrawal accidents happen |
| Mid July – early August | Next-year enrolments appear; last year's records may still be active | Still paused | Decide explicitly which year the extract filters on, then check the batch before sending it |
| Two weeks before day one | Schedules built; late registrations arriving daily | Resume, attended | Run nightly and check the counts every morning |
| First fortnight of term | No-shows withdrawn, transfers processed, contacts corrected at the door | Safe, but noisy | Expect high change counts. That is families fixing phone numbers, which is good |
The mid-June to early-August block is the whole reason this table exists. A nightly job left running unattended through rollover will, on some night, receive an extract that legitimately contains a fraction of the previous roster. Kastr aborts that run rather than accepting it, which is correct behaviour and still not a substitute for pausing the job and checking the counts yourself.
The extract, entity by entity
eSchoolPlus districts typically already run scheduled extracts for state reporting, and the fastest route is to reshape one of those rather than build from nothing. Whatever you start from, the extract joins three things.
- Student registration. A stable student identifier, local or state, pick one and never change it, plus legal and preferred name, date of birth if you use it for matching, and the building. Preferred name is what should appear in a message to a family.
- Enrolment. Current status and entry or withdrawal dates. Status drives who is in the batch: active students go in, withdrawn and transferred students are left out so the next sync withdraws them, and prior-year historical rows should be filtered out of the file entirely rather than filtered later.
- Contacts. The adult records, the relationship to the student, the contact priority sequence, the guardian and emergency indicators, and every phone number with its type. Type is what distinguishes an SMS-capable mobile from a landline, and exporting numbers without it is the most common self-inflicted reach problem in this category.
Contact priority decides who goes in. eSchoolPlus holds a priority sequence per contact, and translating it deliberately is worth an hour of somebody's attention. Sequence 1 and 2 are usually the guardians who should receive everything. Lower sequences are frequently emergency-only contacts, an aunt, a neighbour, who should be reachable in a genuine emergency, through your emergency notification system, and should never receive the newsletter. Send guardian-flagged contacts as guardian entries and leave unflagged emergency contacts out: a roster entry has no rank and no emergency-only setting. Districts that send everyone discover the mistake when a neighbour asks to be removed from a school mailing list they never joined.
Preferred language belongs to the adult, not to the student. Where eSchoolPlus holds it per contact, export it per contact. A household can genuinely need Spanish for one parent and English for another, and inheriting language from the student gets it wrong in both directions.
Home Access Center is not a comms platform, and Kastr is not a portal
Worth stating so a district does not buy the same capability twice, or assume a capability neither product has.
Home Access Center is the records surface. Grades, attendance detail, schedules, assignment-level information, a parent logging in to check something. It answers "what is happening with my child" for a parent who has decided to go and look. Kastr does not replace it, does not read it, and does not display anything from it.
Kastr is the outbound surface. A message that arrives on a phone whether or not anyone logs in: SMS and email, with translation preview before sending, a channel and reach preview before you send, quiet hours that urgent-flagged sends bypass, and retries with delivery receipts when a delivery fails. It answers "school needs you to know this now."
The distinction that decides overlap is push versus pull. A portal is pull; families visit it when they think to. A notification is push; it arrives. Districts run both, and the mistake is expecting either to do the other's job. Be aware of a further limit on our side: Kastr sends SMS and email only. There is no voice calling, no mobile push notifications, no attachments, and no photo or video sharing. If your requirement includes app push, that is a real gap and it is better found here than in a demo.
State extracts, PA, AR and DE, and the guardrail during rollover
Reuse what already exists. eSchoolPlus is common in Pennsylvania, Arkansas and Delaware, and districts in those states already produce state-reporting extracts on a schedule, with the student, enrolment and contact entities already joined and already reviewed for accuracy. Reshaping one is usually less work than authoring a new extract, and it has the side benefit that the roster feeding your family messages is derived from the same data your state reporting is derived from. Two cautions: a state extract may filter to a reporting population that is not your full active roster, and it may carry fields you should not export to a comms platform. Read it before you reuse it.
The rollover, mechanically. During the mid-June to early-August window an extract can legitimately contain a small fraction of the previous night's roster, last year's students closed out, next year's not yet fully registered. Kastr computes what accepting the batch would do before writing anything. If it would withdraw more than half of active records, the run records aborted_guardrail, writes nothing, and leaves the previous roster standing.
The guardrail is a floor, not a plan. A night that withdraws 40% of your roster passes the guardrail and is still probably wrong. Pause the nightly POST for the rollover window and run it by hand, checking the batch's counts against eSchoolPlus before each POST; there is no dry-run mode. Resume when the numbers look like a school district again. Two weeks a year of deliberate attention prevents the failure this whole mechanism exists to catch.
One further point to plan around rather than discover: what a withdrawal does at send time. A withdrawal in the roster marks the person withdrawn and writes it to the append-only audit log, and audience resolution filters out suppressed and retired people when a message is sent, which includes anyone a roster sync has withdrawn. Removing a family from your messaging is a roster operation, with no separate audience clean-up. Ask every vendor you evaluate the same question in these words: when a student is withdrawn in tonight's file, what stops the message tomorrow? Ours is that send-time filter.
Questions people actually ask
Does Kastr replace Home Access Center?
No. HAC is a portal families visit to look at grades, attendance detail and schedules; Kastr is outbound notification that arrives on a phone whether or not anyone logs in. Kastr reads nothing from HAC and displays nothing from it. Districts run both, and the failure is expecting either to do the other's job. Note also that Kastr sends SMS and email only: there is no voice calling, no mobile push notifications and no attachments.
Which eSchoolPlus contact fields drive urgent-message recipients?
The contact records, the relationship to the student, the guardian and emergency indicators, the contact priority sequence, and every phone number with its type, all applied in your export. The top sequences go in as guardian entries and receive everything; lower, emergency-only contacts stay out, because a roster entry has no rank or emergency-only setting. Phone type is what lets your job send the mobile rather than a landline.
Can I reuse an existing state-reporting extract as the Kastr feed?
Usually yes, and it is normally the fastest route in Pennsylvania, Arkansas and Delaware districts, since the student, enrolment and contact entities are already joined and already checked. Read it first for two things: whether it filters to a reporting population narrower than your active roster, and whether it carries fields you would rather not export to a communications platform.
What happens during the eSchoolPlus summer rollover?
An extract can legitimately hold a fraction of the previous roster while last year closes out and next year is still registering. Kastr computes the effect before writing: a run that would withdraw more than half of active records aborts with an HTTP 409 and changes nothing. Do not rely on that alone. Pause the nightly POST from mid-June to early August, run it by hand, and check the batch's counts before each POST and before resuming.
One price. Every feature. Locked for three years.
$3.50 per student per year under 5,000 students. No tiers or add-on modules. Normal messaging is included under a published fair-use allowance, with transparent cost recovery only above it.