What Do You Do When an Automation Runs Twice or Sends Duplicates?

Detailed Explanation

An automation that appears to run twice — two identical emails sent, a task created twice, a customer notified about the same order confirmation two separate times — is one of the more disorienting things to debug in an automation platform, because the workflow itself often has no obvious bug. The step-by-step logic is usually fine; the trigger simply fired more than once for what was, from your perspective, a single event.

This is a general troubleshooting problem that spans any automation platform and any kind of triggered action, which is what distinguishes it from how do you prevent duplicate records when syncing two systems — that page covers one specific mechanism (matching records across two systems using a shared key) for one specific symptom (duplicate customer or contact records). This page covers the broader question of why a trigger fires twice at all, and how to make any workflow resilient to it.

Why Triggers Fire More Than Once

At-least-once delivery from webhook-based integrations. Many platforms sending webhooks guarantee an event is delivered at least once, not exactly once — if your workflow doesn't respond quickly enough, or the sender interprets the response ambiguously, it retries the same webhook call, and your automation processes what looks like a new event but is actually a repeat.

Overlapping polling windows. A trigger that polls a data source on a fixed interval (checking "any new records since I last checked") can occasionally pick up the same record twice if the check windows overlap slightly around the boundary — a record created right at the edge of a polling interval is the most common victim.

A manual retry after an apparent failure. If a run looks like it failed (a timeout, an ambiguous error, a slow response) but actually completed successfully, retrying it manually produces a genuine duplicate — the first run's actions already happened; the retry repeats them.

A workflow re-triggered by its own output. Less commonly, a workflow's action (writing to a system) itself satisfies the condition that triggers the same workflow again, creating a loop that looks like duplication but is actually the workflow re-triggering itself.

Fixing It: Make the Workflow Idempotent

Check for prior action before taking it, using a unique identifier. Before sending an email, creating a task, or writing a record, check whether an action already exists for this specific event's unique ID (an order number, a webhook's event ID, a record's own ID) — if it does, skip the action instead of repeating it. This is the single most reliable fix, because it makes the workflow safe regardless of how many times the trigger actually fires.

Use the sending platform's own idempotency key, if it offers one. Some platforms (particularly payment and messaging APIs) let you attach an idempotency key to a request, so the platform itself recognizes and ignores a duplicate request carrying the same key — check whether the specific service you're integrating with supports this before building your own duplicate-detection logic from scratch.

Add a short delay-and-check step for polling triggers near interval boundaries, if duplicates are specifically tracing back to records created right at a polling window's edge — a brief buffer that re-checks whether a record was already processed in the prior run closes this specific gap.

Log every trigger event with its unique ID, not just successful actions. A log of trigger events (not just completed actions) is what makes it possible to actually confirm whether a specific event fired the workflow more than once, rather than guessing from downstream symptoms alone.

Diagnosing Which Cause Applies

1. Check the automation platform's own run history for the affected period. Two separate runs close together in time, both tied to the same source record or event, points to the trigger firing twice rather than one run doing something twice internally.
2. Confirm whether the trigger is webhook-based or polling-based. This immediately narrows the likely cause — webhook retries and polling-window overlaps have different fixes.
3. Check whether a person manually re-ran the workflow around the time the duplicate appeared. A manual retry after an apparent (but false) failure is one of the most common and most overlooked causes.
4. Confirm the workflow doesn't write something that satisfies its own trigger condition, if the duplication pattern looks like a rapid, repeating loop rather than a single clean double-fire.

Things to Consider

• Idempotency is a design property to build in from the start, not a patch to add after the first incident. Any workflow that takes a consequential action (sending something to a customer, writing a financial record) benefits from a duplicate-check step built in during design, rather than treated as an edge case to handle only after it's caused a visible problem — see how do you test an automation workflow before turning it on for catching this during testing rather than after a customer notices.
• This is distinct from the sync-specific duplicate-records problem, even though both involve "duplicates." Confirm which one you're actually dealing with before applying a fix — a sync's shared-key matching solution doesn't address a webhook retry, and vice versa.
• Customer-visible duplicates (a doubled email, a doubled notification) deserve a quick acknowledgment if a customer notices. A brief, honest note that a system glitch caused a duplicate message is generally better received than no acknowledgment at all.
• Internal duplicates are just as disruptive, only quieter. A Slack notification posted twice for the same event trains a team to skim past channel alerts the same way a doubled customer email erodes trust — see how do you automate notifications and workflows in Slack for building a notification flow worth trusting in the first place.

Common Mistakes

• Assuming the workflow's own logic is broken and rebuilding steps that were never the problem. In most cases the individual steps work correctly; the trigger firing twice for one event is the actual cause, not a flaw in what happens after the trigger fires.
• Adding a delay to "slow down" the trigger without addressing why it fires twice. This can mask the symptom occasionally without fixing the underlying at-least-once delivery or polling-overlap behavior, and makes the real cause harder to diagnose later.
• Manually retrying a run that looks failed without first confirming it actually failed. Retrying a run that had already completed is one of the most common ways a business creates the exact duplicate it's now trying to debug.
• Conflating this with sync duplicate-records prevention and applying the wrong fix. A shared-key matching rule solves duplicate customer records from a sync; it does nothing for a webhook that fired twice for the same event.