Airtable Forms That Collect Clean Data: Conditional Logic, Prefilled Links, Hidden Fields, and Payments

Most Airtable bases are fed by a form. Job requests, client intake, timesheets, purchase approvals, event signups — the form is the front door, and everything downstream inherits whatever it lets through. Yet forms are usually the last thing anyone designs: someone clicks Create form, drags in every field, and ships it. Three weeks later the base is full of half-filled records, three spellings of the same company, and a Notes field doing the job of six.

This tutorial covers how to build Airtable forms properly: which form surface to use, how to branch, how to prefill, how to keep linked-record pickers from exposing your data, and how to stop duplicates and spam at the door.

Step 1: pick the right form surface

Airtable now gives you more than one way to collect a submission, and they are not interchangeable.

Classic form view. A form attached to a single table, shareable by link, no login required. Simple, fast, still the right answer for a public intake form.

Form page in Interface Designer. A form inside an interface, which means it can sit next to other pages, respect interface permissions, and be shown to logged-in collaborators or external users of that interface. Use this when the submitter needs to see anything else — their own past submissions, a dashboard, instructions — or when you need the submission tied to a known user.

A third-party form builder (Fillout, Jotform, Typeform, and similar) writing into Airtable via integration or API. Reach for one only when you need something Airtable genuinely does not do: multi-page forms with saved progress, file-size limits beyond Airtable's, payment collection, e-signature, or per-question logic more complex than Airtable's branching.

A rule of thumb: start with a native form, and treat moving to a third-party builder as a decision with a cost — another vendor, another integration to monitor, another place your data lives.

Step 2: design the fields before you design the form

A form is a view of a table. Bad forms almost always trace back to bad field design, and no amount of form styling fixes that.

• One fact per field. If you ask "What do you need and by when?" in one long-text box, you cannot filter, sort, or automate on either half. Split it: Request type (single select), Needed by (date).
• Prefer select over text for anything you will group or report on. Free text creates "Acme", "ACME Ltd", and "acme " in the same column. See our data quality tutorial for the cleanup you avoid by doing this.
• Do not ask for what you can derive. Region from country, quarter from date, priority from a formula. Every derived field you ask a human for is a field a human can get wrong.
• Mark fields required in the form, not in your head. Required is a form-level setting in Airtable; the underlying field has no required constraint. Anything created by API, automation, or paste bypasses it entirely, so put a validation formula behind anything critical.

Step 3: branching with conditional logic

Airtable forms support show-if conditions: a field appears only when an earlier answer matches a condition. This is the single highest-value form feature and the most under-used.

A worked example for a consulting intake form:

1. Request type — single select: New base build, Fix an existing base, Integration, Training, Other.
2. What is broken? — long text, shown only if Request type is Fix an existing base.
3. Which systems? — multiple select, shown only if Request type is Integration.
4. Team size to train — number, shown only if Request type is Training.
5. Budget range — single select, always shown.

Three practical rules for branching:

• Condition on selects, not on text. Conditions on free text are brittle and unreadable six months later.
• Keep the tree one level deep where you can. Conditions that depend on conditions are hard to test and hard for the next person to change.
• Test every branch. Open the live form URL and walk each path end to end. Hidden-but-required fields are the classic failure: a field marked required inside a branch that never shows can silently block or confuse submitters depending on configuration. Submit a real record on each path and look at what lands in the table.

If your branching starts to look like a decision tree with eight leaves, that is usually two or three separate forms pointed at the same table, each with its own link and its own prefilled Request type.

Step 4: prefilled and hidden fields

Airtable form URLs accept prefill parameters. Append ?prefill_<Field name>=value to the share link and the form opens with that value filled in. Combine it with ?hide_<Field name>=true to prefill a value the submitter never sees.

https://airtable.com/app.../pag...form
  ?prefill_Source=Newsletter%20March
  &hide_Source=true
  &prefill_Request+type=Training

Field names with spaces are URL-encoded (%20 or +), and the parameter must match the field name exactly, including case. This unlocks a lot:

• Attribution without tracking code. One form, a different Source prefill per campaign, newsletter, or partner. Now your reporting can group by channel.
• Per-client links. Prefill and hide the Client linked record so a vendor's submissions arrive already linked to the right account.
• Automation-generated links. In an automation, build the URL with the record's own values and email it. A "confirm your details" form that arrives pre-populated gets answered far more often than a blank one.

Two cautions. Prefilled values are visible in the URL and editable by anyone who reads it — treat hidden fields as convenience, not security. And if you rename the field, every link in the wild silently stops prefilling; keep a small table of the prefill links you have published so the rename checklist has something to check.

Step 5: linked records without leaking your data

Putting a linked-record field on a public form is the most common way bases leak. By default the picker can let a submitter search your entire Clients or Projects table, which means an anonymous form can become a customer-list browser.

Safer patterns, in order of preference:

1. Do not ask. Prefill and hide the link (Step 4), one link per client or project.
2. Limit the picker to a filtered view. Airtable lets a linked-record field restrict record selection to a specific view; point it at a view containing only records that are safe to show, and check what the record titles reveal.
3. Collect a key instead. Ask for an order number or email, then have an automation find the matching record and set the link server-side. The submitter never sees the table.
4. Move the form behind a login. An Interface Designer form page shown only to named collaborators, with Current user filters doing the scoping — see Interface Designer in 2026 and our client portals guide.

Also check the field's allow adding new records setting. Left on, a public form lets strangers create rows in your Clients table, complete with whatever name they typed.

Step 6: de-duplicate on submit

Forms create records; they never update them. Ask the same customer to submit twice and you get two records. Since Airtable has no unique constraint, handle it in an automation:

1. Trigger: When a form is submitted (or When record created on the table).
2. Step: Find records in the same table where a normalised match key equals the new record's key. Build the key as a formula field, for example LOWER(TRIM({Email})), so casing and stray spaces do not defeat the match.
3. Step: Conditional logic. If the find returned more than one record, set Possible duplicate to true and link the new record to the original; otherwise continue as normal.
4. Optional: Update record on the original with the newer values, then mark the new submission as merged, so humans work from one row.

Do not delete duplicates automatically. Flag them into a review view and let a person merge, because linked records hanging off the row you delete disappear with it.

Step 7: spam, abuse, and volume

Any public Airtable form URL will eventually find a bot. Practical defences:

• Ask one question a bot answers badly. A required single select with a business-specific option list filters out generic form-spam scripts better than any honeypot.
• Route, do not block. Send every submission into a Triage view. An AI field agent or a formula on the email domain can tag obvious junk so it never notifies anyone.
• Keep notifications conditional. Trigger Slack or email alerts on "record matches conditions" (not spam, score above a threshold) rather than on every creation, or the team learns to ignore the channel.
• Watch attachments. Attachment uploads on a public form consume workspace storage that you pay for. Cap what you ask for, and see our attachments at scale tutorial if files are central to the workflow.
• Rotate the link if it gets abused. Regenerating the form share link kills the old URL — which is also why the prefill-link inventory from Step 4 matters.

Step 8: what happens after submit

The form is half the experience. Decide deliberately:

• Confirmation message. Say what happens next and in what timeframe. Include a contact route for people who realise they made a mistake.
• Redirect URL. Native forms can redirect to a URL after submit; send people to a thank-you page you control so analytics and any follow-up sequence can pick them up.
• Receipt email. An automation that emails the submitter a summary of what they sent prevents half your support volume. Include a prefilled edit link if they need to correct something.
• Internal notification with context. Notify with the fields that decide who picks it up, not the whole record.

When Airtable's own form is not enough

Switch to a dedicated builder when you need:

• Payment at submit. Collecting card details means Stripe and a form platform that integrates with it; do not attempt to capture payment data into an Airtable field.
• Long, saveable forms. Multi-page applications where people need to come back tomorrow.
• Complex validation. Regex patterns, cross-field arithmetic, address lookup, or calculated quotes shown live to the submitter.
• Compliance requirements around consent capture, e-signature, or data residency.

When you do go external, keep the base as the system of record: write submissions in via API or a documented integration, log every inbound payload, and alert on failures the same way you would any other automation you cannot afford to have fail silently.

A form review checklist

Run this before you publish any Airtable form, and once a quarter on the ones already live:

• Every field is one fact, and selects are used wherever you will report.
• Required fields are set, and anything critical also has a validation formula behind it.
• Every conditional branch has been submitted once on the live URL.
• No linked-record field exposes a table you would not publish; allow adding records is off unless you meant it.
• Prefill and hide parameters are documented in a table, with the field names they depend on.
• A dedupe automation exists, flagging rather than deleting.
• Submissions land in a triage view, and notifications are conditional.
• Confirmation text, redirect, and receipt email are all set.

BaseBrainers builds and audits Airtable intake systems — forms, portals, triage automations, and the schema underneath them — as part of our Airtable database design and development work. If your front door is letting messy data through, tell us about it.