The Jotform Airtable integration exists because a form and a database solve different halves of the same job. The form collects. The base organizes. Connecting them looks like the obvious move, and for a lot of teams it is. What is less obvious is the shape of the seam: the integration runs in one direction, it depends on a permission grant that can quietly lapse, and the free tier of the destination fills up faster than most people plan for. This is a walkthrough of what actually crosses the boundary, what does not, and how to decide whether the two-tool setup is the right one for handling responses.
What the integration actually does
Airtable's own integration listing describes the scope plainly: it sends Jotform submissions to tables in multiple Airtable bases. That sentence contains the two facts that matter most. Submissions move to Airtable. Nothing moves back.
Setup happens on the Jotform side. In Form Builder, the path is Settings, then Integrations in the left menu, then a search for Airtable. Authenticating asks for the email address on the Airtable account, then presents a permission screen where either Add All Resources or Add a Base grants access. After that, three configuration steps finish the job: Choose a Base, Choose a Table, and Match Your Fields.
The field matching step is manual and it is the step that determines whether the integration is useful or merely connected. Each form field gets pointed at a column in the destination table. A form with fifteen questions needs fifteen decisions, and a form that changes later needs those decisions revisited.
One integration can also fan out. Jotform's documentation notes that adding a new action inside the Airtable integration window sends the same submissions to more than one base, and that additional Airtable accounts can be connected alongside the first. That is useful when one intake feeds both an operations base and a reporting base, and it is a trap when nobody remembers the second destination exists.
Airtable's listing adds two details worth noting before committing. The required subscription level is listed as Free and up, and the Airtable permissions required are listed as none. The integration is also categorized as iPaaS only rather than native, which matters mainly for how support questions get routed when something stops working.
What breaks, and why
The public record on this integration is mostly made of people asking why it stopped. Airtable's community forum carries threads about fields not mapping, about linked record fields specifically, and about submissions that populated fine and then stopped. The failure modes cluster into four kinds.
The first is the permission grant going stale. Jotform's documentation is explicit about this: the platform remembers the access permissions for the bases selected most recently, and during re-authentication the same bases have to be added or selected again. Skip that and, in the documentation's own words, an existing integration may stop working. Nothing announces the break. Submissions keep arriving in Jotform and stop arriving in Airtable, and the gap gets discovered when someone goes looking for a record that should be there.
The second is field type mismatch. A text answer lands in a text column without incident. A linked record field in Airtable is not a text column, it is a pointer to a row in another table, and a plain string coming out of a form does not automatically become that pointer. The community threads on this subject are the practical evidence that it needs handling rather than assuming.
The third is schema drift. Renaming a form field, adding a question, or restructuring the destination table can leave the mapping pointing at something that no longer matches. The integration was configured against one shape and the shape moved. This is the most common cause of partially populated records: most columns fill, one or two are blank, and the blank ones are the ones that changed.
The fourth is direction. Deleting or editing a record in Airtable does not reach back into Jotform, because the flow does not run that way. Two copies of the same submission now exist and they can disagree. Whichever one a person happens to open becomes the version they act on.
Where the record limits decide how long this lasts
The integration's useful life is bounded by the destination's capacity, and the free tier is smaller than people expect. Airtable's plan documentation lists the current limits as follows.
| Plan | Records per base | Attachment storage per base | Revision history |
|---|---|---|---|
| Free | 1,000 records | 1GB | 2 weeks |
| Team | 50,000 records | 20GB | 1 year |
| Business | 125,000 records | 100GB | 1 year |
Airtable's pricing page lists Team at $20 per user per month billed annually and Business at $45 per user per month billed annually, with Enterprise Scale priced on request. The pricing page also notes that read-only collaborators, form submissions, and share links do not consume a seat on Team and Business.
Two numbers on that table deserve attention for an intake use case. The 1,000 record ceiling on the free plan sounds generous until submissions are records: an intake receiving 40 a week reaches it inside six months. The 1GB attachment allowance on the free plan is the tighter constraint whenever the form accepts file uploads, because a single resume or scanned document can run several megabytes. Airtable's FAQ does state that reaching a record or attachment limit does not remove existing data, so the failure is a stop rather than a loss.
The source side has its own ceiling. Jotform's pricing page lists Starter at $0 per month with 5 forms and 100 monthly submissions, Bronze at $39 with 25 forms and 1,000 submissions, Silver at $49 with 50 forms and 2,500, Gold at $129 with 100 forms and 10,000, and Enterprise at custom pricing with both listed as unlimited. Starter through Gold are described as single-user plans, which is the detail that catches teams: the submission quota is usually not what forces the upgrade, the number of people who need access is.
Stacking the two sets of numbers is the honest way to budget this. A form on Jotform's Starter plan feeding an Airtable free base gives 100 submissions a month against a 1,000 record destination. That combination is a pilot, not a system.
Editing a submission is a separate decision
Jotform's setup flow includes an optional checkbox labeled Create a New Record When Submission is Edited. It is one checkbox and it changes the meaning of the destination table.
Leave it off and an edited submission does not produce a second row. Turn it on and it does, which means the table holds both the original answer and the corrected one as separate records. Neither behavior is wrong, but they suit different jobs.
A table used as an audit trail wants the new record. Seeing that an applicant changed a phone number, and when, is the point. A table used as a working list does not want it, because now two rows describe one applicant and a count of rows overstates the number of people. Anyone filtering that table has to know which convention is in force, and that knowledge lives in the head of whoever configured the integration.
The decision is worth writing down next to the base rather than leaving it implicit. Six months later, a duplicate row is ambiguous evidence: it could be an edit, a double submission, or a second person with the same name. The convention is what disambiguates it.
The part neither tool covers
Both tools do their half well. What sits between them is the reason people come looking for this integration in the first place, and it usually does not get solved by connecting them.
The gap is ownership and state. A submission arriving in a base is a row. It is not assigned to anybody and it does not know whether it has been answered. Teams close that gap by adding two columns, one for owner and one for status, and then maintaining them by hand. That works as long as somebody remembers. On a busy week nobody does, and the columns drift from the truth within days of being introduced.
The reply is the other half of the gap. The answer to a submission almost always goes out by email, and the email goes out from a mail client. That means the record of what was sent lives somewhere the base cannot see. Checking whether a person was already answered requires opening a second application and searching it. The number of those round trips scales directly with volume, which is why the shortcut of skipping the check appears exactly when volume is highest. Double replies and missed replies both start there.
A third piece is the notification. Airtable can trigger on a new record, but the trigger tells the team a row arrived. It does not tell them who should handle it, and it cannot tell them whether someone already has.
None of this argues against the integration. It argues for being clear about what the integration is for. Moving submissions into a base to be sorted, filtered, related to other tables, and reported on is a real job and Airtable is good at it. Running the reply cycle is a different job. Deciding which one is the actual bottleneck is what tells you whether to wire two tools together or to use one that already covers the sequence from submission to reply. The shapes of intake where that sequence is the whole job are laid out under use cases, and the specific mechanics of owner, status, and reply-in-place are described under features.
Making the two-tool setup survive
If the split is the right answer for the situation, four habits keep it from degrading.
Write down the mapping. A short document listing each form field and the column it targets turns a silent break into a five minute diagnosis. Without it, the only record of intent is the integration screen itself.
Check the count on a schedule. Comparing the submission count in Jotform against the record count in Airtable once a week catches a stalled integration while the gap is still small enough to backfill by hand. This is the single highest value habit on the list, because the failure mode is silence.
Treat re-authentication as a change with a checklist. When the connection is re-established, confirm that the same bases appear in the grant and that a test submission lands in the right table. Jotform's own documentation flags this as the moment integrations break.
Decide the record limit plan before reaching it. At 1,000 records on the free plan, the options are upgrading, archiving older rows to a second base, or moving off the pairing entirely. Choosing in advance is cheaper than choosing while intake is blocked.
What to change first
Start by measuring the gap rather than the tooling. Count how many times in the past month a submission was answered twice, missed entirely, or looked up in two places before anyone could tell what had happened to it. If that number is near zero, the Jotform and Airtable pairing is doing its job and the only work left is the four habits above.
If the number is not near zero, the problem is the seam rather than either tool, and adding another automation across it makes the seam wider. In that case the thing to try is the sequence from submission to reply on one screen, with an owner and a status on every response by default, which is what Halict is built to do.
Q1. Does the Jotform Airtable integration sync both ways?
No. Airtable's integration listing describes it as sending Jotform submissions to tables in Airtable bases, and there is no documented reverse path. Editing or deleting a record in Airtable does not change anything in Jotform, so the two copies can disagree without either tool noticing.
Q2. Will existing submissions be sent to Airtable when the integration is set up?
Jotform's documentation for the integration covers authentication, base and table selection, and field matching, and does not describe a backfill of prior submissions. Plan on exporting anything collected before setup and importing it into the base separately, rather than expecting the connection to pick it up.
Q3. Why did the integration stop populating records?
The most commonly documented cause is the permission grant. Jotform's help article states that it remembers the access permissions for the bases selected most recently, and that during re-authentication the same bases must be added or selected again or the existing integration may stop working. The other frequent causes are a renamed or added form field that no longer matches the mapping, and a destination column type such as a linked record that a plain text value cannot populate.
Q4. How many submissions can this setup hold before something has to change?
The binding limit is usually Airtable's, not Jotform's. Airtable's free plan allows 1,000 records and 1GB of attachments per base, which an intake receiving 40 submissions a week reaches in roughly six months, sooner if the form accepts file uploads. Team raises it to 50,000 records and 20GB at $20 per user per month billed annually. On the Jotform side, the Starter plan allows 100 monthly submissions across 5 forms at no cost.