Sistava

Zapier Duplicate Triggers: Why Your Zap Keeps Running Twice

How-to — — by Mahmoud Zalt

Why one record fires a Zap twice, how Zapier deduplication really works, and the documented fixes for duplicate records in your CRM or spreadsheet.

Two identical rows in the sheet. Two contact records for the same person. Two invoices, two emails, two Slack messages. Duplicates are worse than a broken Zap, because a broken Zap fails loudly and a duplicating Zap quietly poisons your data until somebody complains.

The frustrating part is that Zapier does have deduplication built in. It just protects a narrower area than most people assume, and understanding exactly where the protection stops explains almost every duplicate you will ever see.

How does Zapier deduplication actually work?

For polling triggers, Zapier asks your app for data on a schedule and gets back a mixture of new and old records. It compares each record's unique ID against IDs that Zap has received before. A new ID runs the Zap. A familiar ID does not.

Two limits on that mechanism cause most duplicates. Zapier states that instant triggers do not use deduplication, because apps using webhooks only send new data. And the memory belongs to one Zap, so two Zaps watching the same source both see every record as new to them.

SituationDeduplicated?What that means for you
One polling trigger, one ZapYesThe same record will not run the Zap twice
One instant trigger, one ZapNoIf the app sends the event twice, the Zap runs twice
One source, two ZapsNoBoth Zaps fire on the same record, independently
A record the Zap itself updatesDepends on the triggerA New or Updated trigger can catch its own edit and loop

Read that table twice if you have inherited someone else's account. The most common duplicate in a busy workspace is not a bug at all: it is two Zaps, built months apart by two people, both watching the same form.

What causes duplicate data?

Zapier documents five causes on its duplicate data page, and it is worth checking them in this order because the first two are the cheapest to rule out. Only after those should you go looking for anything clever.

Zapier's own diagnostic advice here is good. Go to Zap history and search for the affected runs using a unique identifier that appears across the duplicated records, then open several run details to see where the data was received and where it was sent. That usually names the guilty Zap in a couple of minutes.

How do you stop duplicates at the destination?

The most reliable fix is not to stop the second run, it is to make the second run harmless. Zapier's guidance is to use a find or create action where the app supports it, so new data is only made if a matching record does not already exist.

This is worth reaching for first because it survives causes you have not found yet. A Zap that looks for the record before creating it produces the same result whether it ran once or five times, which is a much stronger guarantee than trying to make the trigger perfect.

How do you stop duplicates at the trigger?

When the destination has no find or create action, you build your own memory. In a featured community article, a Zapier staff member published a method using a Code by Zapier step backed by Storage, and it is the pattern most Solution Partners point people at.

Building your own deduplication

  1. Add a short delay first, if needed — The article suggests a one minute delay after the trigger when duplicate events tend to arrive close together.
  2. Add a Code by Zapier step — It takes two input fields, a storageKey and a dedupeKey.
  3. Give it a unique storage key — The article recommends generating a UUID and using a different one for each Zap, so their memories never overlap.
  4. Map the record ID into dedupeKey — Use the unique ID from your trigger. That is what the step remembers having seen.
  5. Add a Filter on the result — The step returns a previouslySeenValue boolean. Continue the Zap only when it is false, meaning this record is genuinely new.
  6. Know the memory limit — The article states Storage holds up to 500 unique record IDs and cycles out the oldest ones once that is exceeded.

That 500 limit is the detail to plan around. On a low-volume trigger it will never matter. On something busy, a record from three weeks ago may have fallen out of memory, so this is a guard against near-duplicates rather than a permanent record of everything you have processed.

What if it is a loop rather than a duplicate?

Duplicates that keep arriving are a loop, not a duplicate. Zapier documents three shapes: one Zap's action triggers a second Zap whose action triggers the first, an action that triggers its own Zap, or a New or Updated trigger firing on a record the Zap itself just updated.

Their instruction if you are in one is immediate. Turn off the looping Zap right away, and if two are looping together, turn off both. Then check Zap history to confirm it has stopped and to see how much it ran while you were not looking.

To prevent it, Zapier suggests writing a unique marker into a field when the Zap processes a record, then adding a Filter with a does not contain condition so marked records are skipped. A dedicated processed field works the same way, and Find or Create actions stop the two-Zap version producing new records at all.

It is worth noticing what all of these fixes have in common. Every one of them is you teaching a system a piece of judgement that any person doing the job would already have: do not write this contact twice. A worker who understands the goal never needs that rule spelled out, which is the thinking behind Sistava.

Telling a worker the rule once

You hire an AI Employee and tell it in plain English to add new enquiries to the CRM and never create a second record for someone already in there. It checks first because that is what the instruction meant, not because you wired a lookup step in front of a create step. You can see the ready-made roles at Sistava.

What this will not fix

Some duplicates are not yours to solve, and knowing which is which stops you rebuilding a Zap that was built correctly.

To Zapier's credit, deduplication working at all across thousands of third party apps is genuinely hard engineering, and their documentation is honest about where it stops rather than pretending the problem does not exist. The awkwardness is that a workflow made of steps has no concept of the record it is protecting. If you would rather describe the rule once and be done, Sistava is free to try on one real task.

FAQ

Why is my Zap running twice for the same record?

The usual reasons are that two Zaps are watching the same trigger, or that the trigger is an instant one. Zapier states deduplication applies to polling triggers within a single Zap, and that instant triggers do not use deduplication because webhook apps only send new data. A loop or a replayed timeout can also produce a second run.

How does Zapier deduplication work?

With a polling trigger, Zapier periodically asks the app for data, then compares each record's unique ID against IDs that Zap has received before. A new ID runs the Zap and a familiar ID does not. The memory belongs to that one Zap, so a second Zap on the same source sees every record as new.

What causes duplicate data in a Zap?

Zapier documents five causes: using static values instead of mapped dynamic values, broad trigger settings, multiple Zaps using the same trigger, unintentional Zap loops, and timeouts where a replayed action creates a second record.

How do I stop a Zap creating duplicate records?

Zapier's guidance is to use a find or create action where the app supports it, so a record is only made if it does not already exist. Other documented options are adding a Filter step to narrow which runs continue, tightening the trigger settings, and using Paths instead of two separate Zaps on the same trigger.

Can I build my own deduplication in Zapier?

Yes. A featured Zapier Community article by Zapier staff describes a Code by Zapier step backed by Storage, using a unique storageKey per Zap and a dedupeKey mapped from the trigger's record ID. It returns a previouslySeenValue boolean, and you add a Filter to continue only when it is false. The article notes Storage holds up to 500 unique IDs and cycles out the oldest.

Do Filter steps cost tasks?

No. Zapier's task usage documentation states that Filter and Paths steps do not count as tasks, along with Formatter, Delay, Looping, Digest, Zapier Manager and Storage steps. That makes filtering out unwanted runs a cheap way to control both duplicates and usage.

Sources