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.

Jun 24, 2026
Airtable for Schools: Linked Tables for Accommodations
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
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

Recommended Airtable table structure (schools + accommodations)

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.
If you want help restructuring your Airtable base, book a free consulting call: https://connex.digital/book/website