Airtable for Schools: Linked Tables for Accommodations
Learn a practical Airtable base design using linked tables to track student accommodations, tests, concerns, and out-of-cycle needs in one scalable system.
If your school is using Airtable like a “fancy Excel” with hundreds of columns in one table, you are not alone. The fastest way to make the system easier to use is to split that spreadsheet into a small set of linked tables, so staff can generate automatic lists (like “students who need Test A”), track accommodations by application cycle, and capture teacher concerns through an intake form.
Airtable linked tables for student accommodations — Photo by Beau Carpenter on Unsplash
In this guide, we will walk through a practical Airtable base structure for schools that need to track students, testing, accommodations, and concerns.
Why schools outgrow a single Airtable table
A single-table base starts simple, but it breaks down once you need to:
Generate different lists for different tests and testing windows.
Track accommodations that change year to year.
Capture new concerns “out of cycle” when a teacher flags a student later in the term.
Assign ownership and status to follow-ups, rather than relying on memory.
A relational model fixes this by making each real-world “thing” a table and connecting them with linked records.1
Below is a clean, scalable structure that maps directly to the school use case.
1) Students (the hub table)
Each record is one student.
Suggested fields:
Student ID (unique)
Year / Grade
Homeroom / Class
Primary contact info
Status (active, graduated, transferred)
2) Tests (reference table)
Each record is one test type.
Suggested fields:
Test name (for example, “Spelling Assessment”, “Handwriting Assessment”)
Test category
Typical window (optional)
3) Test Sessions (or “Testing”) (the schedule + results table)
Each record is a student taking a specific test in a specific window.
Key linked fields:
Linked Student → Students
Linked Test → Tests
Suggested fields:
Window / Batch (for example, “Spring 2026 – Batch 1”)
Scheduled date
Completed (checkbox)
Result fields (score, notes, evaluator)
Why this table matters: it lets you keep one testing table for all years, then use views to filter to “State Exams 2026” or “DARE Testing 2025” without duplicating tables.
4) Accommodations (the accommodations history table)
Each record is one accommodation request, approval, or renewal.
Key linked fields:
Linked Student → Students
Suggested fields:
Accommodation type
Program or exam cycle (for example, “Junior Cert”, “Leaving Cert”)
Status (draft, submitted, approved, denied, expired)
Effective start / end dates
Notes
This is the table that prevents the “we accidentally re-applied for something they already had” problem, because you are tracking each accommodation decision as its own record.
5) Concerns (teacher intake + follow-up table)
Each record is one concern submitted by a teacher for a student.
Key linked fields:
Linked Student → Students
Suggested fields:
Concern type (spelling, handwriting, other)
Submitted by (teacher)
Date submitted
Status (new, triaged, in progress, resolved)
Follow-up notes
How to create automatic lists like “students needing Test A”
Once your tables are linked, you can create views that do the work for you:
In Test Sessions, create a view filtered to:
Test = “Spelling Assessment”
Window = “Spring 2026 – Batch 1”
Completed is unchecked
That view becomes the “working list” for the staff member entering results.
Because each test session is connected to the student, you can still open a student record and see every test record and result in one place.
Handling “out-of-cycle” students (late concerns)
Out-of-cycle tracking becomes simple when Concerns is its own table.
Instead of relying on fixed deadlines (“we review all 5th years in January”), you can:
Create a view in Concerns called “New this month”.
Create a view in Students called “Has open concerns” using a rollup or lookup.
Optionally, add an automation to notify the coordinator when a new Concern record is created.
Teacher intake form: the easiest way to capture concerns
Airtable forms can create new records directly into a table, which is perfect for teacher submissions.2
A simple pattern:
Teachers fill out a form that creates a Concern record.
The Concern record links to the student.
The coordinator works from a “New concerns” view and updates statuses.
Tip: Keep the form short. The goal is consistent intake, not perfect detail on day one.
Common mistakes to avoid
Duplicating tables by year (for example, “State Exams 2025”, “State Exams 2026”). Use one table plus views.
Storing accommodations only as checkboxes on Students. You lose history, renewal cycles, and auditability.
Letting “status” live in someone’s inbox. Put a status field on Concerns and Accommodations records.
Ready to restructure your Airtable base?
If you are migrating from a single table with “millions of fields” into linked tables, the highest-risk part is mapping fields to the right new tables and preserving history. Our Airtable help resources cover common migration pitfalls in detail.
Connex Digital helps teams build reliable Airtable systems, including relational database redesigns, teacher intake forms, and reporting views.
TripWorks Polaris waiver automation reduces manual checks when TripWorks emails a generic waiver link. Use notifications, email parsing, and a dashboard.
Discover Zapier Tables filtered view limitations and practical workarounds for complex filtering, record lookups, and view management in your automations.