Stop duplicate records in Make with a Data Store

If the same record reaches your Make scenario twice, the second run can repeat work you already did. Make's Data Stores documentation (opens in a new tab) describes storage that persists across scenario runs, so you can check whether an ID is already there.

We built this example in our own Make Free account with fictional order IDs. The scenario saved the first ID. When we ran it again with the same ID, the filter blocked the record-writing module. When we entered a different ID, the scenario saved it. No live orders, emails or webhook deliveries were part of this test.

Use this approach when a recurring workflow needs to remember IDs between runs. For a one-off list, removing duplicate rows in a spreadsheet may be enough.

1. Create a store for the IDs

You need room for one practice Data Store. Make's Free plan allows one store with 1 MB. Check the current plan limits (opens in a new tab) before starting. If your store is already in use, leave it alone. Continue only when you have capacity for a separate practice store.

1. In Make, open Data stores from the left navigation and select Add data store.
2. Enter Seen order IDs practice as the name.
3. Leave Data structure empty. This practice stores only the primary key, which is the ID used to identify each record.
4. Set Data storage size in MB to 1, then select Save.

You should see the new empty store in the list. Keep it separate from records used by a working scenario.

Enlarge image

Full Make Data Store form with Seen order IDs practice, no data structure and 1 MB storage.

×

Open full-size image

2. Add a fictional input ID

1. Open Scenarios, select Create a new scenario, and name it Duplicate ID practice.
2. Add Tools and choose Set variable.
3. Set Variable name to event_id and Variable value to order-1001.
4. Select the module's Save button. Keep the scenario Inactive; use manual runs for this practice.

The variable supplies one repeatable example ID. It is temporary data within the run; the Data Store will remember the ID between runs. Make explains that distinction in its scenario variables documentation (opens in a new tab).

Enlarge image

Full Make Tools form with event_id set to the fictional ID order-1001.

×

Open full-size image

3. Check whether the ID already exists

1. Add a module after Tools. Choose Data store, then Check the existence of a record.
2. Select Seen order IDs practice in Data store.
3. Click Key and select the event_id output from Tools. In this scenario it appears as 1. event_id.
4. Select the module's Save button.

The module's Exists output is a true-or-false value. Both Data Store modules must use the same store and mapped ID. Typing the words event_id into Key would not select the variable's value.

Enlarge image

Full Make Data Store existence check mapping 1.event_id into Key.

×

Open full-size image

4. Write only IDs you have not seen

1. Add another Data store module and choose Add/replace a record.
2. Select Seen order IDs practice and map 1. event_id into Key again.
3. Set Overwrite an existing record to No. Select the module's Save button.

This module will add the unseen ID as a record. It is the final action in this practice.

Enlarge image

Full Make Add/replace a record form mapping 1.event_id and setting Overwrite an existing record to No.

×

Open full-size image

1. Click the connection between the two Data Store modules to open ^{Set up a filter}.
2. Set Label to Only unseen IDs.
3. Under Condition, select the existence-check module's Exists output. Our module number is 2, so the token reads 2. Exists.
4. Choose Boolean operators: Is false, then select the filter's Save button.
5. Select Save on the scenario toolbar.

The filter lets the record-writing module run only when the check returns false. Make's filtering documentation (opens in a new tab) explains how an unmatched bundle stops at the connection. A bundle is one item of data moving through the scenario.

Enlarge image

Full Make filter using 2.Exists and Boolean operators: Is false.

×

Open full-size image

5. Run the same ID twice

1. Select Run once and wait for the run to finish.
2. Open the numbered result bubble above Check the existence of a record. For the first run of order-1001, expect Exists: false.
3. Check that Add/replace a record also ran. Open Data stores in another tab, open your practice store, and check for the key order-1001.

Enlarge image

Full Make first-run output with key order-1001 and Exists false; the record-writing module ran.

×

The first run returned Exists false and reached the record-writing module.

Open full-size image

1. Return to the scenario and select Run once again without changing the ID.
2. Open the existence-check result. Expect Exists: true.
3. Check the filter result and the final module. In our repeat run, Only unseen IDs showed zero passing bundles and Add/replace a record did not run.
4. Change Tools' Variable value to order-1002, save the module and scenario, then run once. This different ID should pass.

We checked the store separately after those runs. It contained order-1001 and order-1002. Repeating order-1002 stopped at the same filter.

Enlarge image

Full Make repeat-run output with key order-1001 and Exists true; the Only unseen IDs filter blocked the record-writing module.

×

The repeat returned Exists true and zero items passed the filter.

Open full-size image

6. Check the missing-ID failure

In a separate manual run, we cleared Variable value. The existence-check module failed with BundleValidationError and Missing value of required parameter 'key'. The record-writing module did not run.

If you try this check, restore order-1002 afterwards, save the module and scenario, and rerun. Our restored input completed successfully and still stopped as a duplicate. Leave the practice scenario Inactive.

Enlarge image

Full Make validation error showing Missing value of required parameter key after the input ID was cleared.

×

Open full-size image

If repeats still get through

Inspect the input Key in each run's existence-check result. Repeated deliveries need the same value. Confirm that both modules use the same store, both map the same ID, and the filter uses Is false. Check the saved module settings after editing.

If Key is empty, fix the source mapping before continuing. Do not leave the writing module's Key blank: Make documents that it generates a new key when that field is empty. A generated key cannot identify a repeated event.

Keep IDs for the period during which you need to recognise repeats. Removing a remembered ID allows that ID to pass again. Records also use the store's limited capacity, so decide what you need to retain before applying this to a growing workflow.

If you connect a webhook or another action

The following limits are based on documentation and the order of the steps, rather than a live webhook test.

Instant webhook scenarios run in parallel by default. Two overlapping runs can both check an ID before either saves it. Make's webhooks documentation (opens in a new tab) describes Process data in order, which makes that scenario wait for its previous execution to finish. It does not coordinate separate scenarios using the same store.

Adding an external action creates a second problem. Save the ID before the action, and an action failure can leave the ID marked as seen. Save it afterwards, and a failure between the action and the save can let a retry repeat the action. This practice does not guarantee exactly-once delivery.

Before sending emails, creating orders or taking payments, check whether the destination supports an idempotency key, an ID it uses to recognise and reject a repeated request. Design and test the failure handling for that destination before putting the workflow into use.

To practise remembering one fictional ID and blocking its repeat, start with Make Free (opens in a new tab). Keep the scenario inactive and test the destination’s failure and duplicate handling separately before adding a real external action.

Sources: Make Data Stores (opens in a new tab), scenario variables (opens in a new tab), filters (opens in a new tab), webhooks (opens in a new tab), and plan limits (opens in a new tab).