SchoolIT.software · A bounded evaluation
Tell us which part of the school day is getting stuck.
Write to [email protected] with one product question and a short fictional example. A message starts a scope conversation; it does not create an account or a support case. Leave credentials, personal records and actual ticket content in the systems already responsible for them.
For identity, explain the relationship you need
A useful identity message says which provider type the organization uses and which direction of trust you want to discuss. Does a staff member need to sign in here through an external provider, or does another application need to trust an already-authenticated session here? Both can involve SAML, but they are different setup questions. You can describe the desired relationship without naming a real user, exposing a certificate bundle or sending a private key. Plain language about the two applications is enough for the first exchange.
Say whether your question is about a missing configuration, an expected refusal or the scope of the described implementation. An unconfigured provider is off; the reverse SAML issuer is inert without its required identity and credentials. This contact page cannot inspect or activate that setup. If you already operate a service and need incident support, use its established channel. A marketing conversation should not become an informal request for secrets or a substitute for the authorization needed to change a provider relationship.
For interoperability, name the format and the missing decision
Describe whether the consuming application expects a OneRoster-shaped output or an Ed-Fi projection, and which field or row behavior you need to understand. Do not attach a roster. The complete consent contract may already answer a question about directory-field suppression, redact versus omit, or student birthDate being null in Ed-Fi. If the requirement is not covered, state it as a question instead of assuming a mode setting can relax the rule. The projection's shape and the permission to disclose are separate matters.
Keep the null-identifier and staff scope limits in view. The pure gate's emit branch without a student identifier is a limitation of the described boundary, not a recommended way to prepare data. A request involving new minor-data handling or a new consent operation needs a separate reviewed scope. For the initial exchange, a field name and a fictional structural example are enough. You do not need to prove the business need by sending a suppressed value or a real person's record through a public product address.
For an LMS launch, describe the registration question
A launch conversation can begin with the kind of platform and the relationship you expect. The described LTI registration includes issuer, client identity, accepted deployments and signing-key location. If your question is which configuration source applies, say that: a stored registration takes precedence over configuration for the same school. You can explain the presence of two sources without sending their actual contents. The useful first result is a shared understanding of the lookup question and the intended launch, not a copied token to inspect.
This site does not register a platform or perform a launch test. It also does not establish that a listed platform is already connected for your school. A later operational discussion needs its own scope, including the specific setup to inspect and the outcome to verify. Keep the initial message focused on that decision. Avoid bundling a launch issue with unrelated roster or ticket records merely because the same staff member encountered them. Separate examples make it easier to identify which surface actually needs attention.
For tickets or items, describe the workflow without the record
A fictional adult support request can explain a ticketing need: what the requester wants, what staff action is expected and which status change is unclear. No actual ticket text is needed. The described desk is human-operated and AI triage is disabled. A product question about that lifecycle is different from an urgent issue in a service already in use. This page does not open a case, connect to a shared queue or promise a response time. Use the operational support channel for the latter.
An item question should be equally concrete. Are you trying to understand textbook issue and return, or are you asking for device enrollment, application push or remote wipe? The instructional-item engine does not make those device controls available. Stating the real need early can identify a mismatch before anyone prepares a lengthy walkthrough. Use invented labels and no assignment record. The first exchange should clarify the job and the product boundary, not move records into a second informal system for the sake of describing an example.
Make the expected reply small enough to be useful
End the message with one question you want answered. It might be whether the named surface fits the need, which current limitation matters or what a later bounded evaluation would have to show. A broad request to set up everything makes it difficult to distinguish product fit from configuration and authorization. The starting guide offers a brief format if that helps. A few careful sentences usually explain the decision better than an export, a credential package or an unfiltered account of several incidents.
Sending an email shares the content you choose to include with the destination; this page does not supply a special intake mechanism for sensitive records. It makes no automatic deletion or response-time promise. There is no live checkout, account provisioning or provider activation in the contact flow. If a later step would require operational access, establish the specific scope and handling arrangement before sharing anything that depends on it. The immediate outcome should be a clearer question and a concrete next decision, including a decision not to proceed.