I want to build a Make scenario that processes incoming form submissions and stores the results in a spreadsheet or database without creating duplicate records.
What is the problem?
I’m trying to figure out the best way to check whether a record already exists before creating a new one. I know I could search for a matching email address or unique ID, but I’m unsure how to handle cases where multiple submissions arrive close together or the scenario runs again after an error.
Would you recommend using a search module followed by a filter, a data store, or another approach?
I’d appreciate any suggestions on making this workflow reliable, especially when scenarios are retried or processed more than once.
Seconding this, even free tools like Google Forms or Microsoft Forms can do the trick here. I don’t think they detect duplicates, but you could save operations in Make.
in general, my approach would be to use a Search for this, without a data store, since you already keep the submission in a spreadsheet.
The search + filter approach works, but on its own it won’t fully protect you in the two cases you mention. A few things I’d combine:
Use one unique key per submission. Ideally the submission ID your form tool sends. If there isn’t one, build one, for example email + form name + date.
Turn on “Sequential processing” in the scenario settings. Runs then go one after another instead of in parallel, so two submissions arriving close together can’t both pass the “does it exist?” check before either one is written. That’s usually what causes duplicates with search + filter.
Use a Data Store as your “already processed” list, with the unique key as the record key:
Data Store > Get a record (key = your unique key)
Filter: only continue if the record doesn’t exist
Then create the row in your sheet or database
Then Data Store > Add/replace a record with that key
If the scenario runs again after an error, the key is already there and it stops.
For the final write, prefer an upsert when the app has one (Airtable has “Create/update a record”, many CRMs have something similar), so a retry updates the same record instead of creating a new one.
With 1 + 2 + 3 you’re covered in most cases, even when Make retries a failed run.