Zapier creating duplicate records? Check IDs, searches and retries

Find the first place the record repeats

Choose one duplicate and open its runs in Zap history. Write down the Zap name, run ID, source event ID, action inputs, destination IDs and times. Check the destination too. A failed response in Zapier does not prove a record was never saved.

Keep two kinds of ID separate. An event ID identifies one submission or change. An entity ID identifies the client, order or request it concerns. Two submissions can belong to one client. Those submissions may both matter even though only one client record should exist.

Use a stable source ID. A name can change; a timestamp can collide; a new random ID on each attempt makes a retry look new. Stop records with missing required IDs for review instead of guessing a match.

These six examples use made-up records and show expected outcomes, not connected-account test results. Build them in a test destination with outgoing email and payment actions disabled. Keep existing duplicates until their links and history have been checked. Deleting one blindly can remove useful work.

Example 1: the same form event reaches two Zaps

Two published Zaps watch the same form. Each creates a request. The polling trigger returns the stable ID SUB-810 for one submission.

First poll:
Zap A sees SUB-810 -> creates request R-1
Zap B sees SUB-810 -> creates request R-2

Later poll of the same ID:
Each Zap may skip SUB-810 within its own history
The two destination records already exist

Polling-trigger deduplication is kept within each Zap. It can stop one Zap from processing a previously seen trigger ID, but it does not merge the histories of two Zaps. Instant triggers should not be assumed to use that same polling check. The destination action also has its own behavior. Read Zapier's trigger and action rules.

Compare the two destination records' creation times with history. If the same event appears under different Zap names, look for an old published copy, a second team member's Zap or another integration. Search the source app's other connected workflows too. Zapier's duplicate-data guide lists causes to investigate.

If both Zaps do the same job, give that job one owner and disable the redundant workflow after checking what else it does. If they do different jobs, let one create the request and make the other find it by the stable key. Do not assume changing the Zap name changes the underlying event.

Check a fresh submission after the change. Expect one request for its ID and a recorded result for each required action. Then repeat the event through the supported test path. One request appearing twice in history is not the same as two destination records; count the records themselves.

Example 2: a second form should update the first record

Beacon Studio uses an enquiry form followed by a detail form. Both carry the established ClientId. The destination must support an exact lookup on that ID and an update using its own record ID. Confirm those actions before building.

Event SUB-901: ClientId C-42, company Beacon Studio
Event SUB-902: ClientId C-42, detail Preferred start: November

Expected after both:
One client with ClientId C-42
Two separate submission events if you keep an activity history

1. Map ClientId from the current trigger. Do not leave the sample C-42 typed as a fixed value.
2. Search for that exact ID. Check whether the app's search is exact or approximate.
3. For one match, map its returned destination record ID into Update.
4. For no match, use an explicit create path or a supported find-or-create action.
5. For an ambiguous result, stop for review. Do not choose the first similar company name.

Zapier's search documentation describes no-match and multiple-match settings. A halted search does not necessarily stop later actions that have no fields mapped from it. Check every path that can create a record.

Inspect the actual search input and result, not just the green status. A successful search for a fixed test ID can still update the wrong client. Check C-43 with the same company display name; it must remain separate. Test a blank ClientId and an existing pair of duplicate C-42 rows as well.

After the detail form, expect one C-42 client with the new detail. Keep both submission IDs if an activity history is required. Agree what a blank field means before mapping it into Update: leave the existing value, clear it, or request correction. A supported search/create action does not by itself prove two simultaneous first submissions are safe.

Example 3: the create worked but the response timed out

A Zap sends SUB-920 to the destination. The destination saves R-920, but the response never reaches Zapier. History shows an error.

Source key: SUB-920
Destination: R-920 already saved
Zapier: create action reports timeout
Unsafe retry: another unconditional create -> R-921

Look up SUB-920 in the destination before recovery. If R-920 exists, check its fields and capture its ID. If you cannot tell whether the save happened, record that uncertainty and investigate. Another unconditional create can make the problem worse.

An idempotency key lets a supporting destination recognize another attempt at the same operation. Use the same key for the same retry. Support must exist in the API and be available through the action or request method. Adding a field named idempotency does not add that guarantee to an arbitrary app.

Stripe's API documentation gives a concrete example, including matching parameters and a retention period. That is a provider-specific contract, not permanent duplicate prevention for every future request. A changed operation needs its own deliberate identity.

Choose the recovery mode carefully. Failed-step replay and whole-run replay are different. A whole-run replay can repeat earlier successful actions. Zapier's search documentation also warns that replay can reuse the original search output. An old “not found” answer is not a fresh check that R-920 is absent.

For the sample, the expected recovery ends with one SUB-920 record. Keep the original run ID, R-920 and the recovery decision together. Check the destination immediately before any manual action, and account for already scheduled retries. Do not run a manual recovery and leave another automatic attempt free to create the same record.

Example 4: two runs both search before either creates

Two events for ClientId C-88 arrive close together. The destination starts empty. Both runs search, then create.

Run A: search C-88 -> none
Run B: search C-88 -> none
Run A: create C-88
Run B: create C-88

A successful search step has not locked the destination.

Move the uniqueness rule to a place that can enforce it. That might be a unique key on the destination or a supported atomic upsert. An atomic upsert decides whether to insert or update as one protected operation. PostgreSQL documents this for ON CONFLICT DO UPDATE with the required unique constraint or index. Your CRM may offer a different mechanism, or none.

Ask the destination owner which field is unique and how the connected action handles a collision. Do not accept “we search first” as the answer. That is the exact sequence that failed above.

When the destination rejects the second create as a duplicate, handle that specific result. Find the record that won the race, check it belongs to C-88, then continue the remaining work. Do not ignore every error; a permissions failure or invalid field is a different problem.

Delay After Queue can space runs out. It does not enforce a unique key or control a person, another Zap or another integration writing at the same time. Use it to reduce collisions, not as proof that they cannot happen.

Test two attempts close together and include another writer in the test if the production system has one. Expect one C-88 row and an outcome for each event. If the destination cannot enforce uniqueness, document the remaining risk and choose a different write method or a review step.

Example 5: an update triggers the same Zap again

A request app exposes a New or Updated Record trigger. The Zap handles a request once, then updates that same record to mark it processed. The update creates another trigger event.

First event: Request Q-17, ProcessedByZap is empty
Zap finishes the required work
Zap updates Q-17: ProcessedByZap = request-intake-v1
Second event: Q-17 now contains that marker
Expected: filter stops the second event before business actions

For this one-time intake job, add a dedicated marker field that the trigger exposes. Put a filter immediately after the trigger: continue only when that field is empty. Set the marker after the required work succeeds. Zapier documents this pattern in its loop troubleshooting guide.

Check history for a chain of updates to the same record. Different event IDs can still belong to a loop. If the Zap is already repeating, stop the affected workflow and inspect the pending work before changing and restarting it.

The marker handles this specific one-time process. It must not block later legitimate changes that the business expects to process. For recurring work, define an event or version key instead of treating a permanent “processed” flag as the whole solution. Also check whether a manual edit can clear or overwrite the marker.

Expect the first event to finish the work and the marked update to stop. Then change an unrelated field and confirm the agreed behavior. The marker is not a lock: two events arriving before it is written can still collide. If the final marker update fails after the work succeeds, recover the partial result rather than blindly running everything again.

Example 6: the record exists, but the notification is uncertain

SUB-950 should create a request, create an owner task and send one internal notification. The first two actions finish. The notification times out. Keep a recovery log with one row per event and action, using stable keys that a repeated attempt can find.

Event     Action key              Outcome       Destination ID
SUB-950   SUB-950/request         confirmed     R-950
SUB-950   SUB-950/owner-task      confirmed     T-950
SUB-950   SUB-950/notify-owner    uncertain     unknown

Expected recovery:
Keep R-950 and T-950
Check whether the notification was delivered
Resolve that action before marking SUB-950 complete

This is a proposed log structure, not a built-in Zapier guarantee. Choose storage and actions that can enforce any required unique keys. A separate “search the log, then send” sequence has the same race problem as Example 4.

Check the notification provider for a message ID, delivery record or supported retry key. If it cannot prove what happened, leave the action uncertain and send it for review. A “sent” checkbox written before delivery can lose a message; one written afterward can remain blank even when delivery succeeded.

If the notification failed before any send, a failed-step recovery may be appropriate. If it may already have been sent, investigate first. Avoid replaying the whole run just to fix its final action: that can repeat the request, task and notification. Use the documented replay mode and the destination evidence together.

Test a failure after each action and a failure while writing the log itself. Expect the saved request and task IDs to survive recovery. Mark the whole event complete only when every required action has a confirmed or explicitly resolved outcome.

Check side effects as well as records

Keep the recovery instructions beside the Zap. Record the stable event key, destination key, duplicate policy, action owner and which steps may safely repeat. Another person should be able to follow one event from receipt to its final outcome.

• New event: the required record and actions exist.
• Repeated event: no unwanted second record or notification.
• Changed event for the same client: the intended fields update.
• Missing ID or ambiguous match: no guessed create or update.
• Simultaneous attempts: the destination's uniqueness rule is checked.
• Uncertain response: recovery checks the destination before repeating work.

Keep the run IDs and expected results with these checks. One CRM row is not enough evidence if two tasks or messages were created. If the problem crosses several apps, review the whole workflow so the fix covers the later actions too.

Sources

Primary documentation checked September 26, 2026. Actions and replay options vary by app and plan.

• Zapier: trigger and action duplicate handling
• Zapier: investigate duplicate data
• Zapier: search actions and their limits
• Zapier: failed-step and whole-run replay
• Zapier: Delay After Queue
• Zapier: inspect run history
• PostgreSQL: INSERT and atomic ON CONFLICT updates
• Stripe: idempotency keys and retry limits
• Zapier: stop update loops and filter processed records