How to sync Focus School Software with Kastr

Build the report with exactly these columns and the file validates against the endpoint on the first attempt in most districts. The two rows people skip are phone type and the emergency-contact flag, and they are the two that produce complaints from real adults within a fortnight of going live.

Translating Focus contact flags into who gets called

Focus carries several independent indicators on a contact — custody, emergency, lives-with, mailing — and they do not mean the same thing. The translation is a decision your district makes once and should write down.

• Custody flagged → guardian edge, rank 1. Receives everything, including emergency sends that bypass quiet hours.
• Lives-with flagged, not custody → guardian edge, rank 1 or 2 depending on your policy. Usually included in routine sends.
• Emergency flagged only → a contact point with no guardian edge. Reachable when it matters, excluded from routine sends. This distinction is the one that decides whether an aunt three towns away receives the spring concert reminder.
• Mailing flagged → include in routine sends. Where a family has explicitly asked for one adult to receive correspondence, honour it.
• Nothing flagged → do not create a guardian edge. Export it, look at the list, and hand it back to the office. An unflagged adult attached to a student record is usually a data-hygiene finding rather than a recipient.

On consent state. Kastr contact points carry both a validation state and a consent state, the latter mattering for 10DLC and TCPA purposes. Focus is unlikely to hold a text-messaging consent field, so decide your district's position with counsel and set it deliberately on import rather than defaulting silently. Do not import a consent state you cannot evidence — recording consent you did not collect is worse than recording none.

Scheduling the export, and the first three nights

The recipe most Focus districts land on:

1. Build the Advanced Report with the columns above, filtered to active enrolments in the current year.
2. Schedule delivery to a district-controlled SFTP location overnight. Focus can schedule report delivery, so nobody needs to remember to run it — which matters, because a roster that depends on a person remembering will fail in week three.
3. Cron a POST from a district machine using the MIT-licensed Kastr CLI or plain curl, pointed at POST /api/v1/roster/sync. The job runs on your infrastructure with a key you generated and can revoke; we hold no credentials to Focus and cannot reach into it.
4. Dry run for three nights. The diff engine SHA-256 hashes each record payload and classifies add, change, unchanged and withdraw, returning the ledger without writing anything.

What the three nights should show. Night one: everything is an add. Night two: almost everything unchanged, a handful of changes. Night three: a small number of genuine adds, changes and withdrawals. If night three still reports thousands of changes, the payload contains something non-deterministic — a generation timestamp, a re-ordered contact list, a trailing whitespace difference. Fix that before going live, or the ledger becomes noise you stop reading.

Then reconcile five counts against Focus before it goes nightly: active students; student-guardian pairs; distinct guardians (which should be lower than the pair count, and if it is equal your de-duplication is not working); students with at least one SMS-capable number; and students with no contact point at all. That last list is the most valuable thing the exercise produces. Hand it to the office and fix it in Focus — Kastr never writes back, so a correction made downstream is overwritten by tonight's file.

The guardrail applies here as everywhere: a run that would withdraw more than half of active records aborts with aborted_guardrail and writes nothing. Pause the job during your year-end and rollover windows and run it attended.

Florida districts: survey windows, public records and retention

Focus has a large Florida footprint, and two state-specific realities interact with a communications roster.

The FTE survey calendar. Around survey weeks, enrolment records receive concentrated attention — corrections, reclassifications, status changes processed in batches. A nightly sync will show elevated change counts during those periods, which is normal and not a defect. What matters is that you know the weeks in advance so an unusual ledger does not trigger a false alarm, and so nobody accepts an anomalous file because they assumed it was survey noise. Mark the survey weeks on the same calendar as your rollover pause.

Public records. Florida's public-records framework is broad, and messages sent by a district are frequently records. Two practical consequences. First, write every message expecting to see it disclosed with its timestamp. Second, you need a message log whose integrity you can demonstrate rather than merely assert: Kastr keeps a per-district append-only audit log with a SHA-256 hash chain, each entry hashing the previous one, with UPDATE and DELETE revoked at the database role level and no update policy to fall back on. That produces a log that can be shown to be unaltered. Which specific records are exempt, and how student-record confidentiality interacts with disclosure, is a question for your district's counsel and not something a vendor page should answer.

Retention, stated honestly. Kastr derives a retention class from a person's role at creation — student, guardian or staff. What does not exist yet is automated enforcement: there is no scheduled job deleting records when a retention period expires, and there is no cryptographic proof of deletion. If your records-management policy requires enforced destruction on a schedule, that is a real gap today and you should hear it from us rather than discover it during an audit. Clause 7.1 gives you the contractual right to export everything, machine-readable and without fee, at any time — a right we honour on request, not a self-serve button.

Questions people actually ask

Related