Five surfaces. Five different questions to answer.

Identity: establish the sign-in path

The identity surface connects a configured provider with a sign-in flow. Google Workspace uses a hosted-domain allowlist; Microsoft Entra uses accepted tenant identities; SAML can connect an external identity provider to this service. The reverse SAML seam has another direction: an already-authenticated session can be represented to another application through a signed assertion when the required issuer configuration exists. Direction matters. A request to accept a district's sign-in is not the same setup as a request for another application to trust this one.

The useful output of an initial evaluation is a clear account of that direction and its configuration requirements. Keep secret values out of the brief. An unconfigured provider remains off, and absent reverse-SAML issuer credentials leave issuance inert with 501. Those are meaningful limits. They do not describe the access rule for a ticket, a roster output or an instructional-item action after sign-in. If an evaluation ends at successful authentication, it has answered the identity question only; downstream permissions still belong to their respective paths.

Roster projection: shape the output without overstating the scope

The OneRoster provider and Ed-Fi student projection offer named output shapes over the platform roster. The distinction matters to a consuming application that expects a particular envelope, but shape compatibility is not certification and does not turn the projection into a complete academic system of record. The consent behavior below concerns identified student rows in those paths. A reader should not infer a universal platform rule from the presence of a roster feature, and an evaluation should not begin by emailing an actual roster.

A useful fictional example compares directory fields, supported structural fields and the disposition of a suppressed row. Redact and omit have different consequences for a client, even though neither grants permission to disclose a suppressed field. The example must also retain the staff and null-identifier limits in the contract. Removing an identifier is not a safe workaround or an invitation to broaden an export. The contract describes an implementation boundary that needs to stay visible when assessing a particular client's needs.

The roster consent contract, including its scope limits

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.

LMS launch: identify the registered platform

LTI 1.3 launch uses a platform registration: its issuer, the client identity, accepted deployment identities and signing-key location. The described implementation can resolve registration from a stored row or configuration, with the stored registration winning for the same school. The output to understand is the chosen registration and the intended launch relationship. A marketing page listing LTI is not evidence that every platform a school uses has already been registered. A related product link does not create that registration either.

In an evaluation, describe a fictional adult staff launch and the configuration question you need answered. Do not paste a token, a private key or a confidential registration into a contact message. If two possible configuration sources are part of the question, explain their roles without their values. The precedence rule helps frame a review, but it does not prove a migration happened without disruption or authorize a change. Any operational setup remains a separate action that needs its own concrete scope and verification.

Help desk: keep a request understandable to a human

The help-desk surface describes durable tickets, reading and listing, status changes and assignment. Its product role is to preserve a request and make staff work visible through a lifecycle. Ticket AI triage is disabled; a person interprets and routes the request. The API's disabled state is part of the capability description, not a hidden optional accelerator that a visitor can switch on. A first evaluation can use a fictional adult request about a sign-in problem, without including a real ticket or the person involved.

Separate three questions in that example: what the requester needs, which status transition is intended and who may perform the action. A legal-transition rule answers a lifecycle question; it is not proof of every access check on every ticket path. The roster consent contract does not answer those ticket questions. This page does not read a ticket, create a support case or establish a response-time commitment. Use the contact route for a product discussion and the authorized operational channel for a service already in use.

Instructional items: issue and return, with a firm device boundary

The instructional-item engine is described for textbook issue and return. Its job is an item assignment and the transition back when the item is returned. That is a concrete workflow, but it is not device-fleet administration. Registering or assigning an instructional item does not install a management profile, enroll a tablet, push an application or wipe a device. Those device capabilities are not wired into this SchoolIT product. A generic engine's possible future reuse is not evidence that those features are available now.

For a first conversation, describe the item workflow in words with invented labels and no personal records. State whether the actual gap is tracking an issued textbook or administering a fleet. If it is the latter, the current product boundary is a mismatch worth recognizing immediately. A walkthrough of an issue-and-return engine should not be allowed to stand in for the missing device controls. This public page performs no item intake, assignment or return; it explains the named surface so a later discussion can stay within a defined scope.