A feature description should also tell you when it is off.

Provider configuration is part of the identity feature

Google Workspace, Microsoft Entra and SAML are the named sign-in paths. Their presence in code does not remove the need for provider configuration. An absent provider is off, and the corresponding user-facing path should not be mistaken for an already-enabled connection. SAML also has two directions: accepting an external identity provider and acting as an issuer for another application. When the reverse issuer lacks entity identity, certificate or private key, issuance remains inert with a 501 response. A useful evaluation makes that refusal explicit.

The identity feature set also names TOTP with recovery codes. That is an account capability, not a reason to include a recovery code or enrollment secret in a product inquiry. Discuss the desired staff workflow and the configuration state without sending those values. A sign-in result answers an authentication question; it does not establish every permission attached to roster, ticket or item operations. The feature boundary is stronger when the page states that distinction plainly instead of treating a successful login as proof of all downstream behavior.

Compatibility and disclosure are different questions

OneRoster 1.2-shaped compatibility describes an output contract that a consuming client may understand. It is not 1EdTech certification, and it does not make this a full academic system of record. The Ed-Fi projection is another named output shape, with student birthDate fixed to null. If a required extract needs that field, the limitation matters before anyone begins an integration discussion. A missing required capability should be visible in the decision, not concealed by the broader claim that a vendor format is supported.

Disclosure decisions have their own scope. The complete contract below distinguishes a current directory_info allowance, the do_not_publish override, redact and omit, and the staff and null-identifier branches. Those details belong beside the feature because a generic consent label would hide what the implementation actually covers. A prospective buyer should use the contract to ask a precise question about the named projection. They should not interpret it as a legal clearance, a rule for every API or a permission to send actual records through this public site.

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.

Registration precedence should remain understandable

The LTI 1.3 feature resolves a platform registration from a stored row or configuration. For the same school, the stored row takes precedence. That makes the choice explicit when both sources exist, which is useful to an administrator trying to understand which registration a launch would use. The named fields include issuer, client identity, accepted deployments and signing-key location. They describe the connection to assess, not a blanket promise that an unfamiliar LMS platform can be launched without setup.

A fictional example can show why the precedence matters without exposing a real registration. Describe an earlier configuration and a later stored entry, then ask which one is supposed to apply. The expected output is an answer about the chosen source and the intended platform relationship. It is not evidence of a zero-disruption migration or a command to alter a district's configuration. This page does not register a platform, inspect a token or activate a launch. Keep the operational change separate from the feature discussion.

The help desk is operated by people

Ticket filing, reading, listing, status changes and assignment are the described help-desk capabilities. The lifecycle uses supported transitions rather than treating every status as interchangeable. AI triage reports disabled, so the page describes human review and routing. That status should remain visible in a feature evaluation. It would be misleading to count an unconnected classifier as an available feature merely because a future design could accept suggestions. No model reads or classifies a ticket through this marketing page.

Access to a particular ticket is a separate question from whether a proposed transition is legal. The roster consent contract does not establish every ticket lookup's rule, and the product description should not make that leap. In an initial exercise, use an invented adult request and describe the intended staff action without real content or account details. A useful result explains the lifecycle decision and identifies what remains to be verified on the relevant path. The site does not create a case or promise a support response time.

Name the missing capability before committing to a fit

SchoolIT does not manage a device fleet. Instructional-item issue and return serves textbooks; device enrollment, remote wipe, configuration profiles and app push are not wired into this product. A team whose central need is those controls should not have to infer the gap from a footnote. The same directness applies to live checkout, ticket AI triage and OneRoster certification: these are not available features here. Ed-Fi student birthDate remains null even when other permitted fields may be emitted.

A feature list is useful when it helps a school choose or decline an evaluation. It is less useful when adjacent implementation facts are allowed to imply a complete deployment. Start with one actual need, describe it with fictional details and compare it with the named capability and refusal. If the fit depends on something outside that boundary, record the dependency before discussing a rollout. The starting guide gives a way to prepare that brief without credentials, personal records or a purchase commitment.