Platform
Built so the answers hold up.
The properties below are unusual enough to be worth stating, and each one is a decision a district's technology director can check.
One server per organisation
- Your own database. Not a shared schema with a tenant column.
- Your own configuration. Including your own Google client.
- Your own sessions. Nothing is brokered through us.
There is no pooled multi-tenant database, because there is no pool. Each organisation's dashboard runs on its own server with its own data. The commercial model is managed service: Alextricity Technologies stands the server up and operates it; the district owns what is on it.
The practical consequence is the one that matters in a procurement conversation. There is no vendor-held copy of your help desk, your asset register or your door log to negotiate the return of.
One app, no customer list inside it
- Type your work e-mail.
- The app asks your own domain whether it publishes a small discovery document.
- It shows you the name and address it found, and waits for you to confirm.
The published app ships with no directory of customers and no server address baked in. It derives the domain from the e-mail and asks that domain's own web server. Nothing is saved until the person confirms the organisation shown.
This is why one binary serves every organisation, and why adding one does not require a new app release.
Access control that is enforced where the data is
Permission is applied in the query, not in the template. A record a view skips is still in the HTML the server sent, and view-source is not a privilege.
Three roles, compared as strings
Administrator, technician and viewer. Anything that can stop a service sits behind administrator — in a school district the technician role is very often worn by a classroom teacher who also runs a building's technology, not by a career systems administrator. An unrecognised role fails closed.
Tighter, never looser
An individual item may be more restricted than the section it sits in, never less. A per-item setting cannot punch a hole in the gate above it, and a restricted category hides its descendants rather than just its own contents.
Every module declares what it owns
- Tables, each with a written purpose.
- Scheduled jobs and the log they write to.
- Retention rules, declared rather than scripted.
Each module carries a manifest naming the tables it owns, the jobs it runs, the logs it writes and the settings it reads. Retention is one of those declarations: a rule the platform's own job executes, acting only on tables the manifest owns and refusing anything it cannot verify.
The reason this is on a marketing page rather than buried in documentation is that it is the difference between a district being able to answer "what do you keep, and for how long?" and having to go and read the code.