School IT, the boring parts done correctly
The sign-in, roster, and ticket layer your school already half-has — wired all the way through.
SchoolIT.software describes five surfaces: SSO against Google Workspace, Microsoft Entra, and SAML in both directions; a OneRoster 1.2-shaped roster feed with the scoped consent contract below; registered LTI 1.3 platform launch; a staff-triaged help desk with AI triage disabled; and an instructional-item issue-and-return engine. It is not a device-management product. A named implementation does not establish configuration for a particular school.
The platform
Five surfaces with different responsibilities
Identity, roster projection, LMS launch, ticket handling and instructional-item checkout solve different jobs. A configured identity provider establishes a sign-in path; it does not establish every downstream permission. A roster projection shapes an output record; it does not certify a help-desk lookup. This site names those boundaries because a single reassuring privacy label would hide the questions an IT team actually has to answer.
SchoolIT is the independent product page for those surfaces. A described route or engine is evidence of that named implementation, not proof of a deployment for your school. Use fictional examples to examine the workflow before discussing any operational setup. There is no provisioning form or checkout on this page.
Identity & single sign-on
Sign in with what your staff already have
Every identity provider below is a real, present-tense latch, not a promise: unconfigured means the corresponding button simply does not render, or the corresponding endpoint returns a clean refusal. Nothing here silently pretends to work when a district has not handed over credentials yet.
| Capability | Status | What actually happens |
|---|---|---|
| Google Workspace sign-in | Built | OIDC against Google Workspace, restricted to a comma-separated allowlist of your hosted domains (the `hd` claim). No client id configured for your school -- the Google button is simply absent, not broken. |
| Microsoft Entra sign-in | Built | OIDC against Microsoft Entra, restricted to your allow-listed tenant ids. Same rule: unconfigured means the button does not render, never a dead link. |
| SAML 2.0, us as the Service Provider | Built | Per-school SAML configuration identifies the external provider through an entry point and certificate, or an inline or fetched metadata document. The relationship needs its own configuration; this product description does not establish how other district applications are configured. |
| SAML 2.0, us as the Identity Provider | Built | The reverse seam issues a signed assertion for an already-authenticated session so another application can trust that sign-in. Without the required entity identity, certificate or private key, the issuance routes remain inert with a 501 response. A named implementation is not evidence that the issuer is configured for a school. |
| Two-factor authentication | Built | TOTP with recovery codes is a named account capability. This public page does not enroll an authenticator or collect a recovery code. Keep enrollment material and recovery codes out of a product inquiry; account setup belongs to a separately authorized operational workflow. |
| LTI 1.3 platform launch | Built | Per-school platform registration names the issuer, client identity, accepted deployment identities and signing-key location. It resolves from a stored row or configuration, with the stored registration taking precedence for the same school. That rule does not prove a particular platform is configured or that later configuration work will never be needed. |
The reverse SAML seam has a different direction from accepting an outside identity provider: a configured issuer represents an already-authenticated session to another application through a signed assertion. Without the required entity identity, certificate or private key, its issuance routes remain inert with a 501 response. That refusal is part of the named implementation; the page does not activate an issuer or establish that another application already trusts it.
Roster interoperability
A standard-shaped projection, with an explicit scope
The OneRoster provider and Ed-Fi projection offer two output shapes over the platform roster. A compatible shape does not make this a full academic system of record, prove certification, or grant an outside client access. The consent rule described here concerns the identified student rows in those specific projections.
This consent description covers identified student rows in the OneRoster provider and the Ed-Fi student projection. It is not a guarantee about every API or help-desk lookup.
Student directory fields require a current directory_info allowance. A missing or unresolvable consent context, a denial, or an expired allowance suppresses those fields.
The do_not_publish decision overrides permission to disclose. Neither output mode can relax that decision.
The default redact mode keeps the supported structural identifiers, status and role while stripping directory fields; omit removes the suppressed row from the response.
Staff and other non-student rows are outside this student gate. The pure gate also emits rows without a student identifier; that branch is a scope limitation, not proof that unidentified student records are safe to disclose.
The Ed-Fi student projection sets birthDate to null even when other fields may be emitted.
OneRoster is 1.2-shaped compatibility, not 1EdTech certification or a full academic system of record. These implementation facts are not legal-compliance clearance.
The distinction between a redacted record and an omitted record matters to a consuming client. A structural identifier can preserve a join without exposing the directory fields. An omitted row cannot be interpreted as evidence that the person or their underlying record does not exist. These output choices do not create permission to disclose a suppressed field.
LMS launch
Launch through a registered LTI 1.3 platform
The platform registration identifies an issuer, client identity, accepted deployments and signing-key location. The named implementation can resolve that registration from a stored row or configuration, with the stored row taking precedence for the same school. An evaluation should identify the intended platform relationship and the configuration question without sharing tokens or secrets through this public page.
The registration rule gives a stored database registration priority over configuration for the same school. That makes the chosen source explicit when both exist. It does not prove that a district has been configured or that a registration change will cause no disruption. In an evaluation, distinguish the source-selection rule from the actual launch result, and define any operational change separately before treating it as a migration.
Setting it up
How a school actually turns each surface on
1. Identity
Describe the provider your staff use and the intended direction of trust. Do not send client secrets or private keys through a product conversation. Required provider configuration is a separate authorized setup; absent configuration leaves the relevant provider off. The initial brief can use a fictional adult sign-in example.
2. Roster interop
Describe the output format and the field requirement without sending a roster. The contract on this page covers identified student rows in the OneRoster provider and Ed-Fi student projection, with explicit staff and null-identifier scope limits. It does not certify every API or establish that an outside client is configured for your school.
3. LMS launch
Describe the platform relationship and which registration source you need to understand. A stored registration takes precedence over configuration for the same school. Any operational registration is a separate authorized action; this page does not perform it or establish that a launch has succeeded.
4. Help desk
Use a fictional adult request to describe the ticket lifecycle and the staff action you need. The named implementation includes filing, reading, listing, status changes and assignment; AI triage is disabled. This description is not evidence of a configured deployment or of every ticket path’s access rule.
How this is different
What changes if you already pay for a rostering-sync tool or a separate ticket system
| Today, typically | With schoolit.software |
|---|---|
| A consuming tool needs a roster in a particular vendor format. | The OneRoster provider and Ed-Fi projection expose named output shapes over the platform roster, with the scoped consent contract below. This describes the projection; it does not establish what a client stores, a commercial fee arrangement or configuration for your school. |
| A team needs an understandable lifecycle for requests that currently arrive through its existing support process. | The named ticket implementation provides durable requests, supported status transitions and staff assignment. The access rule for a particular lookup or action requires separate evidence; the roster consent gate does not establish it. |
| An SSO integration is a one-off engineering project per identity provider your district happens to use. | Google Workspace, Microsoft Entra, and SAML (both directions) are already wired; turning one on is a configuration step, not a build. |
What does NOT change: this is still not a student information system of record, still not a device-management console, and still not an AI-triaged support desk. If any of those three is the actual gap you are trying to close, say so when you reach out — we would rather tell you this is not the right tool yet than let a mismatched expectation surface after you have committed to it.
Help desk
A real ticket queue, triaged by a person
| Capability | Status | What actually happens |
|---|---|---|
| Ticket filing, reading, listing, status changes, assignment | Built | The named help-desk implementation provides durable tickets, reading, listing, status changes and assignment. A supported-transition rule governs the ticket lifecycle. A lifecycle rule is not proof of the access rule for every lookup or action; each path needs its own authorization review. |
| AI ticket triage / auto-classification | Honest-off | Off. A ticket is filed at a sensible default and a human agent reads it, sets its tier, and routes it. The API reports this plainly rather than making something up: there is no classifier running against your ticket text in this configuration, and there will not be one described as live until it actually is. |
The useful help-desk questions are what the requester needs, which status transition is intended and who may perform the action. A supported-transition rule addresses the lifecycle; it does not prove every lookup or authorization path. The roster consent description is not a help-desk access guarantee. Ticket AI triage reports disabled, so this page describes staff review rather than an active classifier. A fictional adult request can frame the evaluation without sharing a real ticket. This public page does not open a case or establish a response-time commitment.
Keep the boundary attached to the claim
A provider registration, a consent decision and a shaped output are three different pieces of evidence. The roster rule does not establish an access rule for a ticket, an identity-provider configuration or an instructional-item request. Each of those paths needs its own authorization and its own observed refusal. A school should not have to infer that separation from a generic platform badge.
The important distinction in the roster output is between allowing directory fields, keeping a redacted structural record and omitting a suppressed row. A successful response is not permission for every field, and a missing field is not a promise that the underlying record was deleted. The contract below keeps those cases separate.
The roster consent contract
This consent description covers identified student rows in the OneRoster provider and the Ed-Fi student projection. It is not a guarantee about every API or help-desk lookup.
Student directory fields require a current directory_info allowance. A missing or unresolvable consent context, a denial, or an expired allowance suppresses those fields.
The do_not_publish decision overrides permission to disclose. Neither output mode can relax that decision.
The default redact mode keeps the supported structural identifiers, status and role while stripping directory fields; omit removes the suppressed row from the response.
Staff and other non-student rows are outside this student gate. The pure gate also emits rows without a student identifier; that branch is a scope limitation, not proof that unidentified student records are safe to disclose.
The Ed-Fi student projection sets birthDate to null even when other fields may be emitted.
OneRoster is 1.2-shaped compatibility, not 1EdTech certification or a full academic system of record. These implementation facts are not legal-compliance clearance.
No face template is computed from a photo on this SchoolIT surface; face recognition is not wired in the shipping configuration of this public SchoolIT page. Ticket AI triage reports disabled. These are present limits of the named surface, not a claim that every unrelated product has been inspected.
What is not built — read this before you buy anything
The device-management question, answered directly
SchoolIT.software does not manage a device fleet. Device enrollment, remote wipe, configuration profiles, app push and a device-management inventory are not wired into this SchoolIT product. If those controls are the primary need, the product described here does not meet it. This is a boundary of the named product, not a claim that every unrelated platform surface has been inspected.
The adjacent implementation is instructional-item issue and return, wired for textbooks. An item can be issued and returned through that named workflow; this fact does not establish a deployment for your school or a device-management capability. A generic assignment engine is not evidence of enrollment, remote administration or application control for devices. Keep those requirements separate when evaluating the product, and use a fictional description without personal records to explain the job you need done.
Also honest-off today
- AI ticket triage — disabled; the described workflow is staff-operated.
- Live checkout — no card field, no price charged, anywhere on this site.
- 1EdTech OneRoster certification — we are shaped-compatible, not certified.
- Student birthDate in the Ed-Fi feed — fixed to null.
What that means for you
A described implementation is not proof of configuration for your school. The named inactive actions remain refused; no capability is activated by reading this page.
Start with a bounded evaluation
Pick one adult workflow: an unconfigured provider, a fictional ticket, a launch with a made-up issuer, or a textbook checkout described with invented identifiers. State the input, the expected refusal and the result you need to observe. Do not send credentials or export a real roster to explain the requirement.
A product description can help frame the evaluation. It cannot prove a live deployment, replace your existing administrative console, or turn this public page into an approved channel for personal records. The contact route is for a scoped conversation; operational configuration is a separate authorized action.
Talk to us
Tell us which surfaces your district actually needs
Start the conversation with one surface and one question: a provider relationship, a roster output requirement, a launch registration, a fictional adult ticket or an instructional-item workflow. Nothing on this page is a live signup form: there is no checkout, no card field, and no price charged today. A short description using invented details is enough to discuss fit before any operational setup is considered.
Questions about SchoolIT.software
What does the roster consent gate actually decide?
This consent description covers identified student rows in the OneRoster provider and the Ed-Fi student projection. It is not a guarantee about every API or help-desk lookup. Student directory fields require a current directory_info allowance. A missing or unresolvable consent context, a denial, or an expired allowance suppresses those fields. The do_not_publish decision overrides permission to disclose. Neither output mode can relax that decision. The default redact mode keeps the supported structural identifiers, status and role while stripping directory fields; omit removes the suppressed row from the response. Staff and other non-student rows are outside this student gate. The pure gate also emits rows without a student identifier; that branch is a scope limitation, not proof that unidentified student records are safe to disclose. The Ed-Fi student projection sets birthDate to null even when other fields may be emitted. OneRoster is 1.2-shaped compatibility, not 1EdTech certification or a full academic system of record. These implementation facts are not legal-compliance clearance.
Does SchoolIT manage a device fleet?
No. The instructional-item issue and return engine serves textbooks. Device-fleet enrollment, remote wipe, configuration profiles and app push are not wired into this SchoolIT product.
Does an absent SSO provider leave an active integration?
No. A provider without its required configuration is off. In the reverse SAML IdP seam, absent entity identity, certificate or private key leaves issuance inert with a 501 response.
Is AI triaging a support ticket?
No. The shipping ticket route reports aiTriage.enabled=false. This page does not read a ticket or ask a model to classify it.
Does reading this page open an account or charge a fee?
No. This site has no provisioning or checkout form. It does not charge a card, activate an identity provider or register an LMS platform.
Does the roster gate establish every help-desk access rule?
No. The roster projection and help-desk routes are separate paths. A consent description about the roster is not evidence that every ticket lookup uses that same gate. Describe an evaluation with fictional examples and no personal records.