Your SIS keeps the record straight. CetusEd keeps the work around it moving and defensible.
Enrollment, demographics, scheduling, attendance, transcripts, state reporting — those stay exactly where they are, and nothing here asks you to move them. CetusEd takes the part an SIS leaves to you.
Where the line falls
- Your SIS owns the institutional record.
- Enrollment, demographics, scheduling, attendance, transcripts, core records, district operations and state reporting. We duplicate none of it, and that is a product decision rather than a gap.
- CetusEd owns the student-success layer.
- MTSS and intervention management, progress monitoring, goals, assessment-informed decision support, the intersections between special education, 504, multilingual services and health — and the evidence trail underneath all of it.
- The two meet at the roster.
- Students arrive from your system of record. Everything this platform learns about supporting them stays here, where the people doing that work can reach it.
A district running both is the normal case. Most already run several specialized platforms beside their SIS.
Three of the four integration stages need an approval CetusEd does not issue
Stages 2, 3 and 4 each require one: partner credentials from the SIS vendor, a data-protection agreement from the district, and identity-provider configuration from district IT. Whoever grants an approval sets its own timing, so the stages are published in dependency order and carry no target dates.
Six systems, from each vendor’s published documentation
The requirements table covers 6 student information and identity systems. Each row cites that vendor’s published documentation, and says so where a requirement is not published rather than estimating one.
Before your district commits to anything
- You look up your own SIS on the requirements table.
- That vendor’s published terms sit in one row, in a form you can forward to your IT director without rewriting it.
- You ask which stage the connector is at.
- The stage names the approval it is waiting on and which organization issues it. There is no percentage.
- You import a roster from a spreadsheet in September.
- Every clock, pipeline and screen runs off it that day, and the same records carry over when a live connector arrives.
A district that cannot integrate this year should still be able to use it this year.
The workflow does not wait for the connector
A roster import gets a district running this term. The clocks, the pipelines and the analytics work identically whether the names arrived through a nightly sync or a spreadsheet somebody exported on Friday — because the orchestration runs on the record itself.
Where we do not know, we say we do not know
Some vendors publish their partner requirements. Where we could not find one published, the row says unknown rather than carrying an estimate. An estimate in that column is indistinguishable from a fact until the integration is underway.