TrackStudents: Systems Architecture — Printable Slide Deck
Technical overview for school IT, privacy and procurement review
Systems Architecture
How authorized school users, student documentation, access control, privacy boundaries and connected services fit together — described at the level a district technology or privacy reviewer needs.
A traceable path from the person to the record.
This overview is written for school technology leadership, privacy reviewers and procurement teams. It explains how access, data and privacy are controlled — not how the application is implemented internally.
What you get
- —A high-level system architecture
- —The access model for every staff role
- —Worked data-flow examples, including PCA and Special Education
- —Encryption, auditability, retention and deletion
- —Device, browser and network review notes
Markers used throughout
What this is not
- —Not a compliance certification
- —Not a marketing overview — that is the How It Works deck
- —Not a roadmap commitment; planned items are labeled
- —Not an internal engineering document
- —Not a substitute for your district's own review
The whole system, top to bottom.
The one-page answer for a review meeting.
Each line is expanded later in this presentation.
Different responsibilities, different access.
Every access point reaches the same protected system. What each one can see and do is decided by role and assignment, enforced server-side and at the data layer — not by hiding buttons.
Administrator
School-level oversight of authorized data within their own workspace, according to the Admin permission model.
Teacher
Works inside the students and classes assigned to them. Creates most classroom documentation.
Instructional Assistant
Works within the classrooms they have been assigned to, according to the IA permission model.
Learning Support
Applicable students and support information, according to assignments and Special Education permissions.
PCA
Documents observations only for the students specifically assigned to that PCA.
Student Kiosk
A limited classroom-facing interface. No grades, no staff notes, no student records, no account.
What each role can reach.
CRITICALHow scope is set
- —Roles and assignments are managed by authorized school staff
- —Removing an assignment removes the access it granted
- —No role grants visibility outside its own school workspace
Enforced below the interface
Access controls are enforced at the data layer in addition to the application interface. Row-level access controls help restrict users to authorized workspace, classroom and student records, so the boundary holds regardless of which screen or link is used.
School A cannot reach School B.
Every record belongs to a school workspace. Data access is scoped by authorized workspace relationships, so one school's staff cannot see another school's classrooms, students or reports.
School A
- —Classes
- —Students
- —Authorized staff
- —Documentation and reports
Reachable only by staff authorized in School A.
School B
- —Classes
- —Students
- —Authorized staff
- —Documentation and reports
Reachable only by staff authorized in School B.
Also isolated
- —Demo and test data is logically isolated from production customer data
- —Billing information is kept separate from classroom records
Why it matters for review
Workspace isolation is the outer boundary. Role, classroom and student-level authorization then narrow access further inside each school.
Teacher records a classroom redirection.
What a teacher creates
- —Daily grades and grading events
- —Positive documentation and notes
- —Redirections and incidents
- —Hall pass events and corrections
What the record carries
- —Who created or changed it, and when
- —The class and workspace it belongs to
- —Its place in the student's documentation history
- —Corrections kept as history where supported
What is checked every time
Authorization is confirmed on the request itself — the teacher, the workspace, the classroom and the student. An interface that displayed something it should not would still be refused at the data layer.
Students do not sign in to the staff application.
CRITICALWhat the kiosk shows
- —The roster for that one classroom
- —Who is currently out, and for how long
- —Available destinations and occupancy limits
- —Minimum identifying detail on a shared screen
What the kiosk never exposes
- —Grades and grading history
- —Staff notes and incident details
- —Special Education or PCA information
- —Administrative or school-wide information
- —A student account or student login
The kiosk is a limited classroom interface, not a full student account, and not a staff login.
Same classroom, narrower authorization.
Worked example
Why this example matters
Membership in a classroom is not enough. PCA documentation access is authorized per student, so a PCA present in a room of twenty students still sees only the students they are assigned to support.
- —Student-level authorization, not just classroom-level
- —Assignments are managed by authorized school staff
- —Removing an assignment removes the access
- —PCA observations retain who documented them and when
Available only through authorized relationships.
What is supported
- —IEP designation
- —504 designation
- —Accommodations
- —IEP goals
- —Progress monitoring
- —Support documentation
Who can reach it
- —Staff assigned to the student
- —Learning Support within their assignments
- —Administrators within their own workspace, where authorized
- —Not visible to unassigned staff
- —Never exposed through the student kiosk
Boundaries
- —Special Education information is available only through authorized role and student relationships
- —Access follows the assignment; removing it removes access
- —Records remain inside the school's workspace
- —Not shared with billing, training or public services
School-level visibility, school-level scope.
What administrators review
- —Documentation consistency across classrooms
- —Positive documentation and redirections
- —Patterns over time
- —Student and classroom documentation history
Aggregation and reporting
- —By class, teacher, student or date range
- —Out-of-class and pass history
- —Reports for meetings and school records
- —Exports the school controls
Scope boundary
Administrative access is limited to the school workspace the account belongs to. Broad visibility inside that school is the purpose of the role, which is exactly why it is treated as a CRITICAL access path and reviewed for legitimate educational purpose.
What the platform stores, by purpose.
Information is organized into distinct domains with their own access rules. Billing and documentation never share a boundary.
Identity & Access
Staff accounts, roles and assignments.
Classroom Data
Classes, rosters and classroom relationships.
Student Documentation
Grades, notes, positives, redirections, incidents, passes.
Special Education Support
Designations, accommodations, goals, progress monitoring.
PCA Documentation
Observations for specifically assigned students.
Reporting
Generated reports, summaries and exports.
Audit History
Who changed what, and when, where supported.
Billing
Subscription and account status. No classroom records.
Protection that does not rely on the interface.
HIGHEncryption in transit
All traffic between the browser and TrackStudents travels over encrypted HTTPS connections.
Encryption at rest
Stored data is protected at rest where supported by the underlying managed cloud platform.
Authenticated access
Protected areas require an authenticated staff account. Sessions are established at sign-in and validated on requests.
Data-layer access controls
Authorization is enforced in the data layer as well as the interface, so it cannot be bypassed by a crafted request.
Infrastructure security posture
TrackStudents uses infrastructure providers that maintain industry-recognized security certifications, including applicable SOC 2 Type II and ISO 27001 controls. Those certifications belong to the underlying service providers, not to TrackStudents itself.
TrackStudents does not claim to hold those certifications.
Not published here
Key management, credential handling, session token internals and secret rotation procedures are intentionally not described in a public document. Schools with security questionnaire requirements can request that detail privately during administrator onboarding.
Classroom documentation, not a student dossier.
STUDENT RECORDWhat the application needs
- —Student identity sufficient to identify the student in class
- —Classroom and staff relationships
- —Performance and documentation records
- —Applicable support information for assigned students
What it avoids collecting
- —Unrelated personal or family information
- —Medical or diagnostic detail beyond documented supports
- —Student-submitted survey responses in normal workflows
- —Anything not needed for classroom documentation
How student information is used
- —Student information is not sold
- —Student information is not used to train AI models
- —No AI model calls in classroom documentation workflows
- —Records stay within the school's workspace unless the school exports them
- —Students do not sign in to the staff application
Corrections are made without erasing the record.
HIGHAudit history
- —Key documentation retains who created it and when
- —Corrections can preserve prior history rather than silently overwriting it
- —Administrators can review documentation history in their workspace
Retention
- —School records remain available while the school account is active
- —Records stay scoped to the school workspace that owns them
- —Schools control their own exports and reporting
Deletion & account lifecycle
- —Authorized staff can remove records within their permissions
- —Inactive and closed accounts follow a defined lifecycle process
- —Schools may request deletion of their data
- —Deletion requests are handled through the school's administrator contact
The school remains the owner of its education records. TrackStudents operates as the service that stores and presents them on the school's behalf.
Who else is involved, and what they receive.
Live today
PowerSchool and Schoology are supported today through staff-controlled file exports and imports, not an automated data connection.
Planned
Planned integrations are directions, not commitments. Any integration is enabled by the school and reviewed for scope first.
What your technology team needs to plan for.
Devices
- —Runs in a modern browser
- —Chromebook, Windows, Mac, iPad and Android tablets
- —No installation or managed app package required
- —Shared classroom tablet supported for the kiosk
Network
- —Standard outbound HTTPS on port 443
- —No inbound firewall rules required
- —No VPN or on-premise server
- —Works on typical school filtered networks
Allowlisting
- —The TrackStudents application domain
- —The managed cloud data platform
- —The billing provider (administrator screens only)
- —The training community (staff links only)
An exact host list for filter configuration is provided directly to school IT on request.
Designed to support the school's obligations.
STUDENT RECORDTrackStudents is designed to support schools in handling education records consistent with FERPA-related responsibilities. TrackStudents does not claim FERPA certification — no such certification exists for software — and the school remains the responsible party for its education records.
FERPA-aligned design
- —Access limited to staff with a legitimate educational interest
- —Role, classroom and student-level authorization
- —Workspace isolation between schools
- —Documentation history retained with corrections
- —School-controlled exports and deletion requests
PPRA considerations
- —TrackStudents is designed to avoid unnecessary collection of sensitive student information
- —No student surveys in standard classroom workflows
- —Documentation is staff-authored classroom observation
- —Schools remain responsible for PPRA obligations for anything they add
Questions a reviewer should ask
- —Which staff roles will be authorized in our workspace?
- —Who assigns classrooms, students and PCA assignments?
- —Which staff need Special Education access?
- —What is our internal retention expectation?
- —Who is our administrator contact for deletion requests?
Where the strongest controls are applied.
Schools requiring additional technical, privacy, or security documentation may request a more detailed review during the administrator onboarding process.