When a form asks for a category and then a subcategory, the second question should already know about the first. Pick “Outerwear” and the next dropdown should offer jackets and coats, not the whole catalog. Air Fill is building exactly that into its forms for Airtable, so the person filling one out reads a short, relevant list at each step and reaches submit without scrolling past choices that were never going to apply.
What Airtable’s forms can and can’t narrow
Airtable does have a piece of this. Its dynamic filtering for linked record fields can limit which records show up in a picker based on another field on the same record, and that filtering can carry into a form. If your “City” field is a linked record and you’ve set it to filter by the chosen “Region,” the picker will offer only the matching cities. For linked-record-to-linked-record setups it genuinely works, and it’s a thoughtful feature to have in the box.
The edges are where it gets tight. As of writing, the narrowing applies to linked record fields, so a plain single select — the field type most forms lean on for a short, fixed list — can’t be filtered this way; you’d have to convert those options into their own table of linked records first. The filter is configured on the field itself, at the base level, rather than inside a single form, so the behavior attaches everywhere that field appears across your base, not only on the one form where you wanted it. Select values have to match exactly, spacing and capitalization included, for a condition to catch. And it’s a paid-plan capability. For a maker who just wants question two to depend on question one, that adds up to a fair amount of restructuring for a fairly ordinary need.
The workaround, and why it wears thin
So people build around it. The common route is to turn otherwise simple choices into linked tables purely so the filtering will engage — a Regions table, a Cities table, a link between them — reshaping the base to satisfy the form rather than the work. Others split one form into several, one per branch, and route respondents by hand or by sending different links to different people. A good number reach for a third-party form builder that offers dependent dropdowns. And plenty just leave the long list in place and trust people to scroll to the right answer.
Each of these costs something. Extra tables mean more to maintain and more that can quietly drift out of sync. Multiple forms mean multiple things to update every time a question changes. A separate tool means another login, another bill, and another place your form logic lives. And a long, unfiltered list is where mistakes creep in: someone picks a subcategory that doesn’t belong to the category above it, and you’re either cleaning that up later or building validation to catch it. The respondent feels it too, especially on a phone, where a two-hundred-item picker is a lot of thumb work to reach the six options that were ever relevant.
How Air Fill handles one choice narrowing the next
Air Fill is a native iOS app that builds and runs your Airtable forms, and dependent choices are a feature we’re actively developing. The setup is meant to be plain and the fill calm: you tell a field which earlier answer it depends on, and when someone makes that first selection, the next field offers only the choices that go with it. Pick a department and the role list shrinks to that department’s roles. Pick a product line and the model picker holds just those models. The rule lives in the form you’re building, so it shapes that form’s experience without asking you to rearrange the base underneath it.
Because Air Fill already renders selections as large-tap cards and chips, a narrowed list is where that design pays off. The respondent sees a handful of clear, tappable options at native speed instead of a long scroll through mobile Safari, and the answer they give is one that actually fits the answer before it. On the building side, this sits alongside the conditional show-and-hide that Air Fill’s Advanced track already handles, so a single form can both reveal a field when it becomes relevant and, once it’s on-screen, keep its choices tied to what’s been chosen so far. You build the dependency once and preview it against the real runtime before anyone else sees it.
We’d rather be straight about where this stands: dependent choices are in development, not shipped today. When it lands, it’s meant to feel like the rest of Air Fill — set the dependency in the editor, watch it work in preview, and let the form carry it from there. What you get at the end is the quiet version of a form that used to need a workaround. Shorter lists, cleaner records, and a person filling it out who never has to wade past options that were never theirs to pick.
Air Fill is an independent app and is not affiliated with Airtable.
