Second scenario, running on sample data
The first scenario handles a form where every field is filled in once. This one handles the part of JetFormBuilder that breaks a straightforward field mapping: a repeat field, where an applicant adds as many rows as they want. Those rows do not arrive the way the other fields do, and what you do about that decides whether they land in Airtable or quietly go missing.
Everything on this page was measured against a live Make webhook rather than described. The submissions below were posted at it in exactly the shape JetFormBuilder posts them, and the values shown are what came back. ← the first scenario
The short version
A repeat field arrives as indexed keys, not as a single field. Make turns those into a proper list, so the rows are there and usable. Two things about that list will break an intake form in production, and neither shows up while you are testing with a filled-in submission: an applicant who adds no rows at all sends something that stops the whole run, and a half-filled row writes a blank preference that looks real. Both are handled below, and both are shown failing and then not failing.
JetFormBuilder Call Webhook · application/x-www-form-urlencoded
JetFormBuilder posts the submission as form data rather than JSON. A repeat field named dealbreakers with three rows goes out like this, one key per row per subfield:
Which means the failure people run into is not the webhook. It is what happens after: the rows are a list, and a field mapping that treats them like every other field has nothing sensible to write.
These are the five shapes a real intake form produces. Every value in the right hand columns is what Make returned, not what I expected it to return.
| Submission | Rows seen | Flattened onto the client record | Outcome |
|---|---|---|---|
| Three rows | 3 | Wants children; Non smoker; Lives within 30 miles | Three preference rows written. |
| One row | 1 | Wants to relocate | One row. A single row still arrives as a list of one, so nothing special is needed. |
| A row was added then deleted, so the indexes run 0 and 2 | 2 | No pets; Same city | Make closes the gap. Two rows, no empty one in the middle. |
| No rows at all | 0 | (empty) | The one that breaks an unguarded build. Handled below. |
| Two rows, the second one missing its criterion | 2 | Wants children; | One row written, one sent to review rather than written blank. |
builtin:BasicFeeder · the Iterator, and why it needs a gate
If the repeat field is optional, sooner or later somebody submits the form without adding a single row. That submission does not arrive as an empty list. JetFormBuilder sends an empty value instead, so the field is a piece of empty text where a list is expected:
airtable:Create a Record · once per row, plus a summary on the client
Repeat rows are one to many, and Airtable is happier with that as its own table. So the scenario writes both, because each answers a different question:
The summary and the count sit on the client record so you can read someone's dealbreakers at a glance in the Clients grid without opening anything. The Preferences table holds one row per entry, keyed back to the client by email and carrying the position the applicant put it in, so it is filterable and groupable when you are actually matching people.
| Client Email | Criterion | Importance | Row |
|---|---|---|---|
| jordan.ellis@example.com | Wants children | High | 1 |
| jordan.ellis@example.com | Non smoker | Medium | 2 |
| jordan.ellis@example.com | Lives within 30 miles | High | 3 |
a filter per row · write it, or flag it
A repeat row where somebody picked an importance and never typed the criterion is the case with no good silent answer. Writing it produces a blank preference that reads as real when you are matching. Dropping it hides the fact that the form let it through, which is worth knowing because it is usually a form problem, not an applicant problem.
So each row is checked as it is written. Complete rows go to Preferences. Incomplete ones go to a review table with the client, the row number and what did arrive, and the rest of the submission is unaffected:
Those two lines are the scenario's own output for that submission, not an illustration of one. The summary on the client record shows the gap too, which is deliberate: it should look slightly wrong there, because it is.
Building this one meant running both through a real Make account, which turned up two things in the first blueprint that a structural check could not catch. Both are fixed in the file below, so it is worth re-downloading if you kept the earlier one.
| What was wrong | What it would have done |
|---|---|
| The Airtable update module was named in the singular. The real one is plural, ActionUpdateRecords. | Make would have refused the import outright with an unhelpful message about a module it could not find. |
| The Set Variables module was missing its scope setting. | It would have imported cleanly and then failed on your first real submission with a validation error that points at nothing in particular. |
Both blueprints now import into a live Make account and come back clean.
The repeat field scenario as an importable blueprint, and the raw record of the live run behind every number on this page.