District & IT

ClassSeats is designed to be local-first and privacy-first: no ClassSeats accounts required, no ClassSeats servers storing student data, and optional, user-controlled sync for cross-device use.

Quick summary (paste into an IT ticket)

  • Purpose: Seating charts, attendance, and student groupings for educators.
  • Data storage: local on the user’s device; optional sync to the user’s own Google Drive.
  • No ClassSeats servers used to store student data.
  • Google Drive scope (if enabled): drive.file (file-level access only).
  • Authentication: Google OAuth (only when Drive sync is enabled).
  • Offline: Core app works offline; sync requires internet.

1) Data model & file format

ClassSeats stores classroom data in a single JSON file per class. The file is owned and controlled by the educator (or the district, depending on Google Workspace configuration).

2) Optional Google Drive access

Drive sync is optional. If enabled by the user, ClassSeats uses the Google Drive API with the drive.file scope. This scope limits access to files created by ClassSeats or explicitly selected by the user via the file picker/open flow.

3) Student privacy posture (FERPA-aligned workflows)

ClassSeats is designed to support FERPA-aligned classroom workflows by keeping student data under existing teacher/district controls.

4) Deployment notes

5) Security & control questions (direct answers)

Can we block Google Drive?

Yes. If Drive access or OAuth consent is blocked in your environment, ClassSeats still works locally; users simply won’t be able to use Drive sync.

Can we audit what gets stored?

Yes. Data is stored as JSON files (local and/or Drive). Districts can apply normal controls for Drive file retention, sharing, and DLP policies.

Does ClassSeats run analytics on student data?

No. ClassSeats is built to avoid ingesting student content into third-party analytics systems.

6) Support

For district questions, pilot discussions, or rollout planning:
Email: support@classseats.com