Hi Monika, this is a clean fit for a contained Make build.
I would start by confirming JetFormBuilder’s webhook payload and Airtable match key, then map one test submission through a search-before-create route. For the first pass I would include one webhook, field mapping, dedupe and update logic, one Airtable destination, and a test checklist.
A $250 fixed pilot is more useful than quoting the whole matchmaking database before seeing the fields. If you share the field list and whether matching is by email, phone, or another identifier, I can tell you what needs to be in the first test.
You mentioned the fields weren’t mapping correctly. If your intake form uses a repeat field, the block where someone can add as many rows as they want, that’s the most likely place for it to go wrong, so I built a second scenario for it and put it next to the first one: IntakeSync - repeat fields from JetFormBuilder into Airtable (sample build)
The rows themselves arrive intact. I posted a JetFormBuilder-shaped submission at a live Make webhook to check rather than guess, and three rows came through as three rows. What breaks is further along. Somebody who adds no rows at all sends an empty value where a list is expected, and that fails the whole run with a 500, so their submission never reaches Airtable at all. The page shows that happening, and then not happening once the scenario counts the rows before it iterates. A row where somebody picked an importance but never typed the criterion goes to a review table rather than being written as a blank preference.
Running both scenarios through a real Make account also turned up two mistakes in the first blueprint I sent you. The Airtable update module was named in the singular when the real one is plural, which would have made the import fail, and the Set Variables module was missing its scope setting, which would have failed on your first submission. Both are fixed, so that file is worth downloading again if you kept it.
The $250 to finalise this against your real base and fields is unchanged, and it covers the repeat field handling too. My email is [email protected].
Monika — if this is still open, I can take the field-mapping problem as a fixed USD 250, two-business-day reliability slice after written scope and protected payment.
I would first capture one sanitized JetFormBuilder webhook payload (including any nested or repeat-field data), map it to the existing Airtable fields, normalize the email key, and make the create-vs-update decision deterministic. The flow would stop safely on missing or ambiguous fields, duplicate matches, malformed email, empty repeat lists, or an Airtable error instead of silently writing a bad record. I would test new client, existing client, malformed/empty input, repeat-field and retry cases with synthetic fixtures, then return the Make blueprint, field map, short runbook and evidence.
This is a RomeoApps-owned, test-led capability offer; I am not claiming an identical client case study. I need only one redacted payload and the Airtable field names/types to confirm the exact mapping. No credentials or real client data should be posted here. Any buyer-owned connection would be least privilege and private; work starts only after written acceptance and cleared payment.
One thing I did not see raised in this thread, and it is what usually breaks intake forms after the first week: duplicates.
JetFormBuilder re-fires the webhook if the first attempt times out, and Make retries on its own. If the Airtable step is a plain “create record”, every retry adds a second row for the same person. In a matchmaking database that is worse than a missing record: two half-filled entries for the same client are hard to spot and hard to merge later.
The fix is small, but it has to be decided before the build, not after: the write is keyed on a stable field from the form (email, or a submission ID), so a retry updates the existing record instead of appending a new one. One extra step in the scenario, and it is the difference between a database you can trust in six months and one you clean by hand.
USD 120 fixed, covering: webhook receiver, field mapping, deduplicated write to Airtable, and an error branch that logs a failed submission instead of losing it. Delivered in 2-3 business days, paid on acceptance after it runs with your real form.
“Mapping isn’t working” with JetFormBuilder into Airtable is nearly always one of
three things, and they’re quick to tell apart:
JetFormBuilder posts field IDs, not the labels you see in the form editor — and
if any field was renamed after the webhook was first set up, Make is still
mapping against the old structure. Re-determining the data structure on the
webhook with one fresh test submission resolves that class of problem
immediately.
The second is silent loss on the Airtable side: single-select and linked-record
fields only accept values that already exist, matched exactly. A select option
with different capitalisation, or a linked record that isn’t there yet, doesn’t
error — the field just arrives empty. Those need either pre-created options or an
explicit find-or-create step.
On the deduplication you mentioned wanting: matching on email works, but normalise
before comparing — trim, lowercase, and decide up front whether a repeat submission
updates the existing record or creates a second one. For a matchmaking database
that rule is worth writing down before the build, not after.
If you can share one real submission payload and the target base structure, I can
tell you which of the three it is rather than guessing.
I work fixed-price per deliverable, async, CET, written briefs over meetings.