An Airtable form is a very good way to get structured data into a base. Link a submission to an existing company record, restrict an attachment field to PDFs, hide half the questions until an earlier answer says they matter, and the row that lands is clean enough to report on without anyone retyping it.
Then somebody has to answer the person who submitted it. That is the point where the setup stops being a database question and starts being an inbox question, and it is worth being precise about where the line falls before adding a third view and a fourth automation to paper over it.
What the form builder actually covers
The form builder is available on every plan, including the free one, and the feature set is wider than most people who last looked at the old form view expect.
Field types follow the base. Text, number, email, URL, single and multiple select, linked records, attachments, and collaborator fields all work in a form. Computed field types are not supported, which is the constraint that catches people designing a form around a formula or a rollup. Those values get calculated after the record exists, not collected from the person filling the form in.
Conditional visibility exists in two forms, and they are gated differently. Airtable's documentation states that conditional fields in forms are available on all plan types, while conditional groups in forms are only available on Business and Enterprise Scale plans. A single question that appears when an earlier answer matches is therefore available at no cost. A whole block of questions that appears as a unit is not.
Prefilling works through an encoded URL, which is how a form gets sent to a known applicant with their name and reference number already in place. After submission, a form can show a custom message, offer a Submit another response button, or redirect to a static address or to the record that was just created. One caveat there is easy to trip over: post-submission URL redirects are not available when a form is embedded. A form embedded in a marketing page cannot hand the visitor onward to a thank you page on the same site.
Notification on submit is handled two ways. Natively, builders can choose base collaborators who will receive an email notification each time a form has been submitted. For anything more specific, automations run on a When a Form Is Submitted trigger.
Appearance is the clearest paid boundary. Adding a cover image to forms requires a Team, Business, or Enterprise Scale plan, and on the free plan the documentation is explicit that there is no header image customization and Airtable branding cannot be removed.
The numbers that decide whether it holds
Forms create records, and records are what Airtable prices and caps. The figures below come from Airtable's own plan documentation and pricing page.
| Free | Team | Business | |
|---|---|---|---|
| Records per base | 1,000 | 50,000 | 125,000 |
| Price per seat, billed annually | $0 | $20 per month | $45 per month |
| Attachment space per base | 1 GB | 20 GB | 100 GB |
| Revision and snapshot history | 2 weeks | 1 year | 1 year |
| Automation runs per month | 100 | 25,000 | 100,000 |
| Automations per base | 75 | 100 | 150 |
| Conditional groups in forms | No | No | Yes |
Two of those rows do more damage than the rest during a busy intake period.
The first is 1,000 records per base on the free plan. A recruitment round, a grant window, or an event with a waiting list will pass that in a single season, and the cap counts every record in the base rather than every submission, so the tables that support the form count against it too.
The second is the seat price. Editors are billed per collaborator on Team and above, and the free plan allows up to 5 collaborators with Editor or Creator permissions plus 50 commenters. Intake work tends to spread: the person who triages, the person who checks eligibility, the manager who reads the list on Fridays, and the finance colleague who only needs to see the paid ones. Each of those who needs to change anything is a seat. Commenters are included at no charge on Business, which softens the read only case on the higher tier but not on Team.
Revision history is the row nobody checks until it matters. Two weeks on the free plan means a question about what a field said in March cannot be answered in May.
Identifying the submitter, and what that costs
Two settings decide who a form will accept. A See who submitted a response option records the Airtable identity of the person filling the form in, and sharing can be restricted to a specific email domain. Both are useful and both require the person to have an Airtable login.
That is the right setting for an internal form. Staff already have accounts, the audit trail is worth having, and nobody drops out because of a sign in screen.
It is the wrong setting for anything facing the public, and the reason is behavioural rather than technical. Every account creation step placed in front of a person who is trying to apply for something loses a percentage of them, and the ones lost are not a random sample. They are the ones on a phone, on a bad connection, or at the end of a working day. A recruitment form, a grant application, and a repair request all want the opposite: the fewest possible steps between reading the page and finishing the submission.
The practical alternative on a public form is to leave identity as a field. Ask for an email address, mark it required, and validate the format. It does not prove who somebody is, and for most intake nobody needed it proved. What matters is having a reachable address attached to the submission so that a reply can go somewhere.
Where the identity genuinely has to be verified, the usual pattern is to keep the form open and verify later in the process, at the point where a decision is being made rather than at the point where information is being collected.
What automations do after the row is created
The When a Form Is Submitted trigger plus a Send an email action covers a real amount of ground. An acknowledgement to the person who submitted, a notification to the right reviewer, a Slack or Teams message to a channel, a record created in a second table: all of that is configuration rather than code.
One detail about run limits is worth knowing before building anything with several steps. Airtable counts an automation run each time a trigger is invoked, regardless of whether the automation's actions run properly. Failures consume the allowance. On the free plan's 100 runs per month, a misconfigured automation that fires on every submission can exhaust the budget during the week it is being tested.
Automations are also where the shape of the work becomes visible. Everything they send is a message the system composes. The template is written once, and each submission fills it in.
Where the replies still live in email
Most of the messages a busy intake desk sends are not templates. They ask for the second page of a document that arrived cropped. They explain why an application does not qualify and what would change that. They chase an answer that was promised on Tuesday. Those get typed by a person, and Airtable is not the place they get typed.
So the reply gets written in a mail client, and three things follow from that.
The record and the conversation come apart. The row says the application arrived on the ninth. The mail thread says a clarification was requested on the eleventh and a reply came back on the fourteenth. Reading one does not tell anyone the state of the other, and the join is a human remembering to look in both.
Ownership becomes a convention. A single select field called Owner is easy to add, and it records an intention rather than a fact. Whether that person has actually written to the applicant lives in their sent folder, which nobody else can see. This is how the same applicant gets two different answers from two colleagues on the same afternoon.
Status drifts from reality. A status field is only as accurate as the last person who remembered to change it after sending something. When the sending happens in a different application from the tracking, the gap between the two is measured in days.
None of this is a defect in Airtable. A base is a database with an excellent form attached to it, and databases do not model correspondence. The alternative shape is a tool where the submission and the reply are the same object, so that sending a message is what moves the status rather than something to remember afterwards. A short tour of what that looks like on one screen is the quickest way to judge whether the difference is worth anything for a given workload.
When an Airtable form is the right answer anyway
Plenty of intake genuinely belongs in a base, and swapping it out would be a downgrade.
If the submission has to be linked to something that already exists, an Airtable form is hard to beat. A maintenance request that must attach to a specific unit, a purchase request that must reference a supplier record, a session sign up that must roll up into a capacity count: linked record fields at the point of entry save the reconciliation that would otherwise happen later.
If the value of the data is in the aggregate rather than the individual case, the same applies. Forms feeding grouped views, rollups, and interfaces produce a reporting layer that a form tool with a response list will not match.
If the number of people who need to change records is small and stays small, the seat pricing is not a problem. One or two coordinators on Team is a modest bill for what the base does.
The honest test is what proportion of the work is a human reply. Where almost every submission ends in one or two messages written by a person, that work is the job, and the tool that does not hold it is the wrong centre of gravity. Where submissions mostly get sorted, counted, and reported on, the base is the right centre and the occasional email is a footnote.
What to change first
Count last month's submissions, then count the individual messages that were typed by hand in reply to them. If the second number is close to the first, the form is not the problem and the reply path is. Put the submission and the reply in the same place, keep the owner and the status on the response rather than in a field someone has to update, and check the pricing model of anything being considered against how many people actually need to touch a response, which is the axis Halict prices on.
Q1. Does an Airtable form support conditional logic on the free plan?
Conditional fields in forms are available on all plan types, so a single question can appear based on an earlier answer without paying anything. Conditional groups, where a block of questions appears as a unit, are only available on Business and Enterprise Scale plans.
Q2. How many submissions can a free Airtable base hold?
The limit is 1,000 records per base, not per table, so every supporting table counts toward it. A form that creates one record per submission will therefore run out well before 1,000 submissions if the base holds anything else. Team raises this to 50,000 and Business to 125,000.
Q3. Can a form redirect to a thank you page after submission?
Yes, a form can redirect to a static address or to the record that was just created. The exception is embedded forms: post-submission URL redirects are not available when a form is embedded, so a form placed inside another page has to use a custom message instead.
Q4. Can Airtable send the reply to the person who submitted?
An automation with a When a Form Is Submitted trigger and a Send an email action handles templated messages such as acknowledgements and rejections. Messages written individually for one applicant are not composed in Airtable, so they end up in a mail client where the base cannot record that they were sent.
Q5. Why does the automation run count go up when an automation fails?
Airtable counts a run each time a trigger is invoked, regardless of whether the automation's actions run properly. Failed runs consume the monthly allowance, which is 100 on the free plan and 25,000 on Team, so a broken automation can use up the budget during testing.