SchoolIT.software · A bounded evaluation

Start with one adult workflow and one expected refusal.

There is no account-creation form here. A SchoolIT evaluation begins by describing the job, the input and the result you need to understand. Use invented details and keep credentials, ticket exports and roster records in their existing authorized systems. Configuration and deployment are separate steps, not consequences of opening this page.

Write a brief that a colleague can understand without a demo

Choose one adult staff workflow. For example, a staff member needs to sign in through a configured district provider, or an administrator needs to understand which LTI registration applies to a launch. Write the job in one sentence and the obstacle in another. You do not need to include a real email address, a tenant identifier or a token. The point of the brief is to isolate the decision. If the description needs five products and several unrelated incidents to make sense, narrow it to the first unresolved step.

Then state the expected output in human terms. The staff member should understand which sign-in path is available; the administrator should be able to explain which registration source takes precedence. Avoid making the output simply a successful response. A response can be successful while a field is appropriately suppressed or while an unrelated capability remains off. A colleague should be able to read the brief and identify the exact question being asked. That gives a later walkthrough a practical purpose beyond displaying a collection of screens.

Describe configuration state without handing over configuration

For identity, name the provider type and whether its required setup exists. Google Workspace, Microsoft Entra and SAML have different relationships to explain. SAML has two directions, so say whether this service would accept an outside provider or act as an issuer for another application. Do not send client secrets, private keys, recovery codes or session material. An initial product discussion can identify the intended relationship without those values. Missing configuration is useful context; secret content is not a prerequisite to explaining it.

For LTI, describe the registration source question. The named implementation gives a stored registration priority over configuration for the same school. A fictional example can compare the two sources without reproducing either. For a roster question, describe the format and field requirement using no records, then keep the full consent contract beside the discussion. For a ticket question, describe an invented adult request and the intended status change. Each brief should remain tied to its own surface instead of using one configuration fact as a proxy for the whole product.

Write the refusal before looking for the successful path

An unconfigured identity provider is off. Missing reverse-SAML issuer identity, certificate or private key leaves issuance inert with 501. Ticket AI triage is disabled. Device-fleet management is not wired into this product, and no live checkout runs on the site. Pick the refusal that matters to the workflow you chose and state what you need to understand about it. A clear refusal can be a correct, useful result. The exercise should not be designed so that every answer must sound like activation or success.

Keep consent questions within the supplied roster scope. A missing directory field is not automatically a bug to work around, and a row without a student identifier is an explicit scope limitation rather than a safe disclosure trick. If a proposed next step would create a new minor-data or consent operation, it is outside the scope described here and needs a separate review. The initial brief should help identify that boundary before a real record is involved. It should never convert an unreviewed requirement into a casual configuration instruction.

Agree on what a later evaluation would need to show

For the identity example, distinguish the provider's configuration from the result of a sign-in. For the launch example, distinguish registration selection from the application behavior after launch. For a ticket, distinguish the supported status transition from the caller's permission to make it. These are different observations, even if they appear close together in a workflow. A concise evidence plan says which observation answers the question and which related questions remain open. It does not claim that one convenient success proves every boundary.

The marketing site can explain source-described behavior and current limits, but it does not run the operational evaluation for a school. If a later step needs access to a provider console or an application account, establish its authorized scope first and make the proposed action concrete. Do not send credentials merely because a conversation has progressed. The useful output at this stage is a reviewable plan for one named surface, with fictional examples still sufficient wherever actual records are unnecessary. Keep the existing service in charge until a separately agreed change occurs.

Choose the smallest next step that answers the real question

A fit conversation may end with a narrow configuration question, a request for further evidence or a decision that another kind of product is needed. If the need is a complete academic system of record, OneRoster-shaped projection is not the same thing. If the need is device control, textbook issue and return is not the missing console. If the need is automated ticket classification, the described triage is human-operated. Those distinctions can settle an evaluation before it grows into an unnecessarily complicated project.

Send the short brief through contact when the question is ready. There is no published response-time commitment on this page, and sending a message does not provision an account, register a platform, change a provider or charge a card. It also does not establish an approved channel for personal records. The desired immediate result is a clear next decision with a stated scope. If the right decision is to wait or decline the fit, the evaluation has still done useful work.