The consent rule needs a scope, not just a reassuring label.

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.

Keep the named path attached to the privacy claim

The OneRoster provider and Ed-Fi student projection are the paths covered by this description. That is a narrower statement than saying every SchoolIT action uses the same gate. A help-desk lookup, identity-provider configuration or instructional-item operation has a different responsibility and needs evidence about its own authorization. A successful result on one path cannot establish what happens on all of them. The wording above deliberately keeps the implementation fact close to its subject so a reader does not have to infer the boundary.

The contract also distinguishes students with resolvable identifiers from staff, other non-student rows and the pure gate's null-identifier branch. Those distinctions are not optional footnotes. The emit branch without a student identifier is a scope limitation and does not show that an unidentified student record is safe to disclose. Do not use the description as a recipe for removing an identifier to change an output. A new minor-data or consent requirement needs a separate reviewed scope; this public page neither performs nor authorizes such an operation.

A suppressed field, a redacted row and an omitted row mean different things

The default redact mode retains supported structural identifiers, status and role while removing directory fields. The omit mode removes the suppressed row from the response. A consuming application therefore may see a structural record in one mode and no corresponding response row in another. Neither result is a statement that the underlying person or record has been deleted. Neither mode can relax the do_not_publish decision. An integration discussion needs to preserve those distinctions instead of treating any successful response as permission for every field.

A useful fictional example can compare expected shapes using field labels and no actual values. Ask what the client is supposed to do with a structural row and what an absent response row means for its own workflow. That is a question about interpreting the output, not a reason to request the suppressed directory information. The current directory_info allowance and its failure cases remain part of the contract. If a client expects a field that the projection does not emit, record the mismatch before assuming the output can be broadened.

A standard-shaped envelope is not permission to populate every field

The Ed-Fi student projection fixes birthDate to null even when other fields may be emitted. That is a concrete limitation for a consuming system with a birth-date requirement. A field's presence in a vendor format does not make it available from this projection. The same restraint applies to the OneRoster description: it is 1.2-shaped compatibility, not 1EdTech certification. The page does not claim a full academic system of record or legal-compliance clearance on the strength of a compatible envelope.

For an evaluation, name the exact field or structural relationship you need and compare it with the contract before discussing a real extract. A fictional example is enough to establish that a required value would remain unavailable. That may settle the fit question early, which is useful. Do not send actual records to demonstrate that a client requires more information. If a requirement depends on a new field disclosure or a different consent behavior, it belongs to a separate review rather than an assumption made during a marketing conversation.

This page is an explanation, not a personal-record intake channel

The SchoolIT marketing surface has no roster upload, account provisioning or live checkout form. Reading the pages does not configure an identity provider, register an LMS platform, file a ticket or assign an instructional item. The apex publishes non-executable structured metadata derived from the same visible FAQ, including the scoped consent answer. That metadata describes the public product page; it contains no operational roster. These are statements about this rendering surface and should not be expanded into a claim about every hosting, email or application system.

An initial contact message should describe the need with fictional details. Leave names, contact information, actual tickets, credentials and exported records in their existing authorized systems. The page does not promise a retention period, automatic deletion, a complete access model or a special secure intake arrangement for email. If a later operational discussion needs any of those, establish the specific handling scope before sharing the information it would govern. A product description cannot supply that agreement simply by linking to a page called privacy.

Other inactive features do not make a broader privacy guarantee

Ticket AI triage is disabled in the named route. This page does not read a ticket or ask a model to classify one. Device-fleet management is not wired into the SchoolIT product, and instructional-item issue and return should not be mistaken for remote device control. Those are useful capability limits, but they do not prove an unrelated route's access policy. The same care applies to sign-in: a configured provider can establish an identity path without settling every downstream permission on a different surface.

For a question about the contract, use contact with a description of the path and the decision, using no personal record. For a question about a service already operating, use its established administrative or support channel. Related-product links let you read each product's own scope; they do not establish a shared account, a transfer of data or an enabled integration. The useful result of this page is a precise understanding of the named rule and its limits, so a later evaluation begins with the right questions.