A Zap created the record twice: find which of five causes it was

Count the runs before you change anything

Open Zap history and find the time the duplicate was created. The number of runs around that moment tells you which half of the Zap to look at. Two runs for one source event points at the trigger side. One run that wrote two records points at the action side. A run followed some time later by a replay points at replay. Write down which pattern you see before you edit anything, because the fixes differ and a wrong fix can hide the real cause.

• Two runs with the same source record ID: a second Zap, or a trigger that fired twice.
• Two runs with different source IDs: two real events, so the Zap is doing what it was built to do.
• One run and two records: two create steps, or a repeated branch inside the Zap.
• A run and a replay: a replay ran a step again that had already succeeded.

Trigger-side causes

Zapier says that for a polling trigger it compares each item's unique ID with the IDs the Zap has already seen, and runs only when it sees a new one. It also says this check works only inside one Zap, so two Zaps built on the same form or app event both fire. Instant triggers do not use the check, because the app is expected to send each event once. If the sending app delivers an event twice, the Zap runs twice.

A Zap can also trigger itself. Zapier's trigger documentation warns that a Zap that writes back to the app and resource it watches can loop, and its loop article lists a trigger for new or updated records that fires again when the Zap's own action edits the record. Look for a Zap whose action changes the same kind of record its trigger watches.

• Search your Zap list for every Zap that uses the same trigger app and event, including old ones that were switched off and on again.
• Check whether the action step edits the record type the trigger watches.
• Ask the source app whether it can send one event twice, for example after a retry.

Action-side causes and replay

How an action behaves when the data already exists depends on the destination app. Zapier's article says that if an app allows duplicate data, Zapier creates a duplicate record; if the app does not allow it, Zapier returns an error; and on rare occasions the app ignores the duplicate. A plain create step is therefore safe only when the destination refuses repeats.

Replay is a second route to duplicates. Zapier documents that replaying from Zap history retries only the steps that errored, while replaying a whole run from the editor re-runs every step, starting with the trigger, whatever happened before. A create step that had succeeded can run again. As a caution rather than a documented rule: a step that reported an error after its request reached the destination may already have created a record, so look at the destination before you replay.

• Treat the editor's full-run replay as a deliberate second run of everything.
• Check the destination for the record before replaying an errored create step.
• Do not replay a run on live data just to test a fix.

What usually fixes it

The durable fix is to make creation find-first. Zapier's loop article recommends swapping plain create steps for find-or-create actions so that an existing record is not duplicated. Its search-step article explains that only some searches offer a create-if-it-does-not-exist option, and that when a search finds nothing the step stops as halted unless it is set to count as successful. Where the app has no such option, a search step followed by a filter or a path can do the same job.

Choose the field that identifies one real thing, such as an order number or an email address, and use that field for the search. If the Zap edits its own source, add a processed marker field and a filter that stops records already marked.

• Write down one unique key for each record type.
• Decide whether a match should be left alone or updated, and which fields may be overwritten.
• Test with disposable records: the same event twice, a full-run replay, and one different event.

What this guide does not cover

This guide does not clean up duplicates that already exist. Merging or deleting records can lose information and needs its own decision about which record wins. It also does not cover a Zap that never starts, or a mapping that drops fields; the existing field-mapping guide covers the second.

The paid outcome for this problem is one Zap and one create step. It is accepted when one synthetic event creates one record, the same event again and a full-run replay still leave one record, and a different event creates its own record. Send the Zap's trigger and destination, with no customer data, and fit is confirmed before any access.