Skip to main content

One row per customer: matching by email when a form or order resends

  • Oct 31, 2026 1:26 PM UTC
  • 1 reply
  • 6 views

Amik_Nag

I built a small flow where Make writes into Airtable and needed exactly one row per lead or order. What worked for me:

Store a lowercased email (or the order ID) as the key and search on it before creating anything.

Use an escaped value in filterByFormula, because apostrophes in emails will break a plain string.

On a match, append to a long-text Message field with a dated divider instead of overwriting, and don’t let blank fields overwrite saved ones (for example, keep the phone number).

 

I tested it on test data, and I can share the field setup if anyone wants it.

 

1 reply

Vadim Ciobanu
Forum|alt.badge.img+2
  • Known Participant
  • Oct 31, 2026 5:26 PM UTC

Nice write-up, Amik, and the lowercased key + escaped filterByFormula are details most people miss. A few things that tend to bite this pattern in production:

  1. Race condition: search-then-create isn’t atomic. When a form or webhook resends within seconds, two runs can both find nothing and both create a row. Turning on Sequential processing in the Make scenario settings fixes it for instant triggers. The Upsert a record module (performUpsert + fieldsToMergeOn in the API) also saves you the search step.
  2. Out-of-order events: if a resent created arrives after refunded, “Last event” goes backwards. Store the source event timestamp and only update when it’s newer.
  3. History in long text: it works, but a linked Events/Submissions table (one row per submission → linked to the customer) scales better. You can filter and report on it, and “Earlier orders” becomes a COUNT() field instead of Make logic.
  4. Worth a fallback key (normalized phone) for when the same person uses a different email.

Would love to see the field setup. Sharing it as a base template would be really useful for others here.