Reference · generated from the product
Integration requirements, by system
Six systems and four integration stages. Three of the four stages require an approval issued by the district, its SIS vendor, or its identity provider.
Source. Every requirement is quoted from the vendor’s own published documentation. Where a requirement is not published, the row records that instead of estimating one.Where a claim carries no verified citation the badge says so rather than the page implying one.
Each stage states the approval it requires before it can begin.
- stage 1 no external approval required In-platform signing and disclosure reporting our lane Multi-party signature capture on one shared device, for signers who are in the room. A district-facing report lists every field a connector would send or receive, generated from the same column list the disclosure check reads. Export coverage extends to the fields a receiving system requires, including the state student identifier.
- stage 2 SIS partner credentials + district data-privacy agreement District-hosted SIS connector runs on the district and its SIS vendor’s calendar The district deploys the connector on its own cloud account, with an allow-list naming only its SIS host. Inbound rostering runs against a test environment before production. Two approvals must be granted first: partner credentials from the SIS vendor, which for Skyward is an Integration Access record issued through the Partner Portal and for PowerSchool is an OAuth client created in the Developer Console; and the district’s data-privacy agreement.
- stage 3 district identity provider configured for external release Remote consent with no student data in the message runs on CetusEd and the district’s identity provider’s calendar The notification carries an opaque token and the student record stays where it is. A one-time code establishes the signer’s identity. A second factor is required when a release sends data outside the district. The signed bytes and the local record are hashed into the existing audit log under a server-issued timestamp.
- stage 4 stages 1–3 complete Two-way field write-back runs on all parties above’s calendar Write-back starts with the small set of fields a receiving system requires, added one field at a time. Each field is reconciled against the source and can be reversed. Every write is authorized at the district’s connector, logged on both sides, and idempotent.
Stages 2, 3 and 4 each require an approval that CetusEd does not issue: partner credentials from the SIS vendor, a data-privacy agreement from the district, and identity-provider configuration from the district’s IT staff. Because the timing of those approvals is set by the organization granting them, the stages are published in dependency order and carry no target dates.
| System | Partner registration | Permission model | Credentials | Standards support | Ongoing burden | Status as of 2026-08-13 |
|---|---|---|---|---|---|---|
| Skyward (Qmlativ)SIS | requiredMandatory. The API is reached through an Integration Access record that synchronizes to Skyward's Partner Portal, and the portal issues credentials. A district cannot simply hand out a key. | district controlledThe Integration Access record declares which tables and fields are exposed and which operations are permitted — read-only is an enforceable configuration the district sets. | per districtUnique credentials per district. No shared secret; revocable by the district alone. | not publicNot stated in the published material reviewed. | not publicNot stated in the published material reviewed. | not startedNot registered. The highest-value partner conversation for a Washington district, and a prerequisite rather than a formality. |
| PowerSchoolSIS & IEP | partialA district administrator can mint an OAuth client ID and secret from the Developer Console for a specific installation; broader distribution runs through the partner program and developer portal. | district controlledPermissions inherit from the creating account, so scope is decided in the district's own admin portal. | per districtPer-installation OAuth client credentials. | not publicNot stated in the published material reviewed. | not publicNot stated in the published material reviewed. | not startedNot registered. |
| Synergy (Edupoint)SIS | partialRostering is the supported path and needs no partner program. Anything richer than roster and enrollment runs through Edupoint's partner relationships. | not publicTerms beyond rostering are not public. | not publicNot stated in the published material reviewed. | supportedThird-party integration is documented via the OneRoster API — the same interface CetusEd already implements. | lowEdupoint's own guidance is to configure a Test/Train site before production, which matches how a pilot should run anyway. | not startedNot registered. OneRoster support means the read direction is largely a credentials-and-agreement problem rather than a build. |
| Branching MindsMTSS platform | not applicableNo open partner API to register against. | agreement gatedPartner data flows require a signed data-sharing agreement between the customer and each party before assessment or goal data moves. | not applicableFile transfer rather than API credentials. | file basedPublished guidance routes student data through secure file transfer or an uploader, with nightly synchronization from the SIS. | district heldA district running both would most likely exchange scheduled files — lower-risk and slower, and a district-to-district decision, since the customer holds both agreements. | not startedNo contact. |
| Microsoft Entra ID & Google WorkspaceIdentity | requiredMicrosoft publisher verification is the trust step for a multi-tenant app: a registered app, a verified publisher domain, and partner-program membership. There is no charge to verify. | district controlledA district can require SSO and disable email login. If the SSO provider is not configured, email sign-in stays available and the fallback is audited — a misconfiguration cannot lock a district out of its own records. | per districtOpenID Connect with PKCE, signature check on by default. | builtSign-in already works against Microsoft Entra ID, Google Workspace and Clever. | high if scoped upGoogle is the steeper one. Anything beyond basic sign-in — Drive, Calendar, mail — means restricted scopes, and those require a third-party security assessment by a Google-approved assessor, RENEWED ANNUALLY, before distribution. | builtSign-in only, deliberately. Reaching into Workspace content would convert a small integration into a recurring annual audit obligation, so it is out of scope by design. |
| OneRoster & Ed-FiStandards | gatedEd-Fi's partner badge has a market-availability bar a pre-pilot company cannot meet: available across an entire US state or purchasable by at least 100 districts, with real district usage. | not applicableNot a permission relationship. | not applicableNot a credential relationship. | partialOneRoster rostering implemented, uncertified. Ed-Fi identifier contract implemented: the record reconciles on the state student identifier and a readiness report names every element still unmapped. NO SUBMISSION IS EMITTED — that needs a server-side client and a DPA decision not yet taken. | sequencedPilots first, then the district count, then certification — not the other way round. | partialOneRoster rostering implemented, UNCERTIFIED, and no conformance certification is claimed. Ed-Fi mapping is earnable; PRODUCIBILITY is not. Certification is a separate and later question. |
estimate I DID NOT RE-VERIFY THESE AGAINST THE VENDORS' LIVE DOCUMENTATION on this date. The chain is vendor docs → the live page → this file. A requirement that changed since the page was written is invisible here, and partner programs change.