iSAMS
Rehearse it, read it, then approve it.
Rafyo reads your iSAMS each night and works out what has changed: new pupils, corrected details, families that have left. It does not act on any of it. Every difference is staged as a proposed change for someone at your school to approve or reject, and you can rehearse the whole thing — against the live roster, writing nothing — before the nightly sync is ever switched on.
Read-only, in one direction
Rafyo pulls pupils and contacts from your iSAMS each night through the Batch API. It never writes back. Ask your iSAMS System Manager for a read-only key scoped to the modules Rafyo actually reads — Pupil Manager and Contacts, Medical if you want dietary records to come across, HR for staff meals — and nothing else is reachable with it.
Rehearse before you switch it on
Before the nightly sync runs for real, you can ask what it would do. The rehearsal fetches the live roster and shows the full diff — and writes nothing at all: no run, no proposals, no baseline. If a first rehearsal proposes a pile of new families rather than almost nothing, identity matching is wrong, and finding that out here costs nothing.
A sync stages changes; it doesn't make them
A run writes proposed changes and leaves your live family and child records untouched. Somebody approves them. Nothing about a pupil moves in Rafyo because iSAMS said so overnight — it moves because a person at your school read the row and agreed with it.
The risky rows are marked as risky
A dietary or allergen change coming from iSAMS is always flagged for review rather than treated as routine, and so is any proposal to archive a child. Archiving takes someone off kitchen lists and their dietary record out of view, so a leaver is only ever proposed — never applied — and only when two independent checks on the feed both pass.
Reviewing makes the pile smaller
Approve or reject a row and it leaves the list. Rejected rows used to stay on screen crossed out for the rest of the run, so rejecting was the one action that never seemed to do anything; they're now one click away under "Show rejected". Each section has a Reject all beside its Approve all.
Billing codes come with them
Each family's iSAMS billing code comes across, and separated parents can each carry their own. That code is what reconciles a payment in your Stripe dashboard — no pupil name has to leave the building for the money to tie out.
Overnight · the review queue
Nothing has changed yet. That's the point.
Each row shows what Rafyo holds and what iSAMS sent, so approving is a decision rather than a leap of faith. Anything touching a dietary record is flagged for review no matter how small it looks.
Sync review · roster from 02:14
18 pending- Class · Rowan P. Update
3 JMK → 4 SDL
- Dietary · Rowan P. Review
Allergen added from iSAMS Medical
- New pupil · Iris M. Create
Reception · one contact matched
Who does what
Your System Manager does
One thing, once: enable the Batch API and issue a read-only key scoped to those modules, with both the IP and domain restrictions set to override. Rafyo stores it encrypted and never shows it back — not to us, not to you.
The office does
Reads a review queue. Changes are grouped, each showing what Rafyo holds against what iSAMS sent, with the age of the roster on the page — because "these are the changes" means nothing without "as of when".
Nobody has to do
Re-keying a new pupil, chasing a changed address, or noticing that a child left in July. If you'd rather not connect the API at all, the same records come in from iSAMS Family and Pupil exports — drag the files in, review, confirm; re-importing merges rather than duplicating.
See a school day with Rafyo
A 20-minute walkthrough with a real menu, a real register and no slide deck.