The first time a scenario of mine processed the same spreadsheet row three days in a row, I understood the problem immediately: Make had no memory. Every run started fresh, checked the sheet, saw the same rows it had already handled, and happily did the work again. The fix turned out to be one of the more useful features in Make.com, and one that beginners tend to skip because the name sounds technical. It is not. A data store is just a small notebook your scenario can write in and read from.
What Is a Data Store in Make.com?
A data store is a built-in database inside your Make account. You create one, define what fields each entry should have, similar to naming the columns of a spreadsheet, and then your scenarios can add, search, update, or delete entries in it using ordinary modules. There is no separate database software to set up and nothing to install. It lives in Make, next to your scenarios, ready whenever you need it.
Think of a scenario as someone with no short-term memory. Each run, it wakes up, does its job, and forgets everything the moment it finishes. A data store is the sticky note that person leaves themselves so the next version of them, running an hour or a day later, knows what already happened.
When Does a Scenario Actually Need Memory?
Not every scenario needs one. A scenario that reacts to a single event, like a webhook firing when someone submits a form, generally has no need to remember its own past, because each submission is a new, separate thing to act on.
Where memory becomes necessary is anywhere a scenario checks a source repeatedly and needs to know what it has already dealt with. Common cases include scanning a shared spreadsheet on a schedule, watching a folder for files, pulling from an RSS feed, or syncing a list from one app into another. In every one of those, without memory, the scenario cannot tell the difference between something new and something it processed yesterday.
What Is the Deduplication Use Case, in Plain Terms?
Deduplication just means not doing the same thing twice. Picture a scenario that scans a spreadsheet of signups every fifteen minutes and sends a welcome email for each one. Without memory, every run resends welcome emails to every row in the sheet, including people who signed up weeks ago. That is not just wasteful, it is the kind of mistake that damages trust with real people.
A data store fixes this by keeping a running list of identifiers, like a row number or an email address, that the scenario has already handled. Each time the scenario runs, it checks the new items against that list before doing anything, and only acts on the ones it has not seen before.
How Do You Add, Search, and Update Records?
Once your data store exists, three modules cover almost everything you will do with it:
- Add a record. This writes a new entry, with values for each field you defined, such as an email address and the date it was processed. Use this right after your scenario successfully finishes handling an item.
- Search records. This looks up whether a matching entry already exists, usually based on one key field. Use this near the start of the scenario, before doing the real work, to decide whether to continue or stop.
- Update a record. This changes an existing entry instead of creating a duplicate, useful when the same item can come through more than once but its details change, like a support ticket that gets updated with a new status.
A filter module usually sits right after the search step, so the scenario only proceeds if nothing matching was found. Our guide to filters and routers covers exactly how that gatekeeper logic works.
What Does a Simple Example Look Like?
Here is roughly how I set up my own row-tracking scenario after that repeat-processing mistake. The scenario runs on a schedule, reads rows from a Google Sheet, and for each row, searches a data store for a record matching that row's unique ID. If a match is found, the scenario stops for that row. If nothing is found, it processes the row as normal, then adds a new record to the data store with that row's ID, marking it as done.
The next time the scenario runs, rows it already handled get filtered out immediately, and only genuinely new rows make it through. It is a small pattern, three modules and a filter, but it is the backbone of a huge share of reliable automations, and it pairs naturally with the scheduling approach covered in our guide to running scenarios on a timer.
How Is a Data Store Different from Just Using a Spreadsheet?
You could technically track processed items in a spare column of your existing spreadsheet, and plenty of people start that way. A data store is faster to search, does not clutter the sheet you actually care about, and is built specifically for this kind of lookup, so scenarios using it tend to run more efficiently than ones adding extra read and write steps against a spreadsheet just for bookkeeping.
I still use spreadsheets for the source data, connected the way our guide to connecting Google Sheets describes, and reserve the data store purely for tracking what has already been handled. Keeping those two jobs separate has made my scenarios easier to read months later, when I inevitably forget exactly how I built them.
What Should You Watch Out For With Data Stores?
Field names matter. If you change what field a search module is checking without updating the records already stored, matches silently stop working, and duplicates start slipping through again. Whenever I redesign a data store's fields, I test the search step by hand with a known existing record before trusting it in a live scenario.
It is also worth checking the storage limits tied to your specific Make plan before building something meant to track a large, ever-growing list, since those limits can change and are best confirmed on Make's own documentation rather than assumed.
Next step: Data stores turn a forgetful scenario into a reliable one, and they show up again and again once you start looking for the pattern. Browse the automation hub for more Make.com scenarios that build on this idea.
