How to Create Dependent Dropdowns in Airtable Forms

A long product list is easier to use when people can narrow it down first. A request for office stationery should not begin with a list of cables, adapters, notebooks and every other item your team maintains.

This tutorial builds a small category-to-product request form with Airtable and miniExtensions. The requester chooses Stationery or Technology, then selects a product from that category. The submitted request stores the product relationship; an Airtable lookup supplies its category for reporting. The example uses fictional office supplies and a deliberately small dataset so you can check every result before adding a larger catalog.

What you will build

The finished workflow has three tables: Categories, Products and Requests. A category narrows the available products, while each submission creates a request linked to one product. This is a selection workflow, not a shopping cart, purchase approval or stock reservation system. A team member still reviews requests and decides what to fulfill.

If you instead need people to browse a gallery and maintain their own selection list, see the Product Catalog walkthrough. Here, the goal is a focused request form with a dependent selector, not a logged-in catalog.

Prepare the tables and sample records

You need an Airtable base you can edit, a miniExtensions workspace connected to that base, and permission to configure a Form. Start with non-sensitive sample records. The following schema is a suggested design for this example, not a template automatically generated by the filtering feature.

Create Stationery, Technology and Furniture in Categories. Add Notebook and Pen Set to Products, linking both to Stationery. Add USB Adapter and Headset, linking both to Technology. Leave Furniture without any products for an empty-results test. Use the linked Category cells rather than typing category names into an unrelated text field.

Before configuring the form, open each product in Airtable and check its category link. An accidental Technology link on Notebook would make the source data wrong even if the form were filtering correctly. Keep the category names distinct and readable; the person completing the form should not need internal codes to make a choice.

Connect the form to Requests

Create a miniExtensions Form for the Requests table, or use a new example form already connected to it. Include Request, Product and Notes. A useful Request value for the first test is “Desk setup for new workspace.” Keep the Product field visible throughout this example.

Open Product in the form’s field settings and enable Required near the top left. This makes selecting a product part of completing the form. A required field that becomes conditionally hidden is not enforced, so do not add conditional hiding to Product while testing this workflow. See the required-field guidance.

Also open Product’s Advanced settings and set Allow users to link to Single Record. Set this explicitly in miniExtensions rather than relying on an inherited preference. The miniExtensions override takes precedence; when no override is stored, the form falls back to Airtable’s preference. The single-record selection documentation explains the distinction.

Add Category as the dynamic filter

In Product’s field settings, open Filter Records, enable Dynamic filtering, and add the Products table’s Category relationship under Filter Fields. Category belongs to each candidate product: it is the relationship the form uses to narrow the product list. Leave this filter visible so the requester can make the choice.

This pattern is documented in the dependent-dropdown setup guide. This example uses the direct Products → Categories link, keeping the first implementation simple.

Do not add a second editable Category input to Requests just to make the filter appear. That creates two separate concepts with the same label: the category used to find products and a category someone could independently enter on the request. The lookup in the proposed schema keeps reporting tied to the product actually selected.

Decide what happens before a category is selected

Open Category inside the filter configuration and turn off Allow adding linked records if this conditional filter is empty. This makes the requester choose a category before using the existing-record selector. It is separate from requiring Product before submission: one controls the selection sequence, while the other controls an incomplete submission.

Importantly, this filter requirement does not prevent creating a new linked record. To restrict this example to existing products, open Product’s Create & Expand Records section and turn off Allow users to create new records. Verify that the end-user form does not offer product creation. This is a separate setting, documented in the linked-record creation guidance. Do not disable creation for the main Requests form: it still needs to accept new requests. See the required-filter instructions and creation exception.

There is a separate control for removal while the filter is blank. Decide whether a requester should be able to clear an earlier product selection without first selecting a category, and test that choice explicitly. Do not treat the add and remove behaviors as the same setting.

Keep the saved category tied to the selected product

The filter is a way of finding a product; it is not an independent answer automatically written into the request. In Requests, the Category lookup follows the selected Product and reads that product’s category. This avoids asking the person to repeat a choice and prevents two editable category answers from drifting apart.

The filter-value documentation recommends a lookup for this purpose and notes an important ambiguity: if a linked item belongs to several categories, its lookup cannot establish which category the requester used to find it. That is why every product in this example has exactly one category. A lookup also represents the current relationship, not a separately captured historical browsing choice.

Run a small acceptance test

Use the end-user form, not just the builder’s list of enabled settings. These are checks to perform on your configuration, not a claim that your form has already passed them.

If any result differs, record the exact category, product and sequence of clicks. Compare the saved record with the visible form. A selector that looks right is not sufficient evidence that the correct relationship was saved.

Extend the workflow without confusing filtering with permissions

After the basic example works, you may want to hide categories that staff should not select. The filter field itself has its own conditions: open it within the linked-field filtering settings and configure Only show linked records that match these conditions. That changes the category choices, rather than merely narrowing the final product list. See filtering the filter fields.

For parent forms, filter values can be supplied through a URL and the controls hidden. The documented visibility option is Hide filter fields (prefill using URL). This option and filter-field prefilling are not available on child forms. When exploring this variation, prefill the filter, not the Product relationship itself; see the prefiltered-form guidance.

Keep the visible category selector for your first version. A hidden control or a prefilled URL is not, by itself, a complete authorization design. This fictional supply form does not establish who may access private products or requests. Treat those requirements as a separate configuration and review task before using sensitive records.

A focused form is easier to maintain

The important relationships are simple: Products belong to Categories; Requests link to Products; the request’s category is derived from that link. With a small test matrix and one product per request, you can distinguish a data problem from a filtering problem. Expand the catalog only after the blank, empty-result, changed-selection and saved-record checks behave as intended.