Imagine an order automation that creates a dispatch request, then loses its connection before receiving confirmation. The run appears to have failed. Someone presses retry, and the warehouse receives another request for the same order.
The same uncertainty can affect customer emails, CRM tasks and invoices. The useful question is not simply whether a workflow can retry. It is whether it can retry without repeating work that already happened.
For a UK business connecting its website, payment provider and operational tools, this deserves attention before the next integration goes live. Here is how to investigate duplicates, recover a failed run and ask for safeguards that protect the customer journey.
Why a failed run can still have done some work
An integration sends a request and waits for a response. If the response never arrives, there are two possibilities: the receiving system did nothing, or it completed the action but the confirmation was lost. A timeout alone does not tell you which happened.
This is why providers document repeat delivery. Stripe’s current webhook guidance says an endpoint can receive the same event more than once, live-mode delivery failures are retried for up to three days, and event delivery order is not guaranteed. A webhook is a notification one system sends to another when something happens.
Those notifications should not automatically become fresh orders or fresh messages every time they arrive. Equally, switching off retries can leave legitimate work unfinished. The aim is controlled recovery, with a clear record of what has actually been completed.
Trace one duplicate before changing the workflow
Start with one affected order or enquiry. Follow it from the original website submission through the automation history to the receiving system. Record the original reference, run identifiers, action times and destination record identifiers.
Work through these questions:
- Was the original action genuinely repeated? Two separate customer submissions need different treatment from two deliveries of one notification.
- Did two routes do the same job? For example, an existing shop integration and a newer automation might both request fulfilment.
- Was a failed step retried, or was the whole workflow restarted? That changes which completed actions could run again.
- Did the destination succeed before the timeout? Check its records rather than relying only on the automation’s error message.
Take a hypothetical enquiry workflow: it creates a contact, assigns a task and sends an acknowledgement. If the acknowledgement fails after the first two actions succeed, restarting everything may be unnecessary. Your investigation should identify the unfinished action and preserve the completed work.
Do not start by deleting duplicate records in bulk. Keep enough evidence to understand the cause, then decide which records and customer communications need correcting.
Define what should happen once
Ask whoever owns the integration to describe its business rule in plain English. For example: one initial dispatch request per order, one acknowledgement per enquiry, or one invoice per agreed billing event.
The technical term is idempotency: repeating the same operation has the same intended effect as performing it once. That does not mean every event for a customer should be ignored after the first. A customer can place another order or submit another genuine enquiry.
Use the right reference for the action
Our practical recommendation is to identify the original business action and carry its reference through each system. An email address identifies a person imperfectly; it does not identify a particular order. A new timestamp generated on every retry does not identify the original action either.
Keep notification identity and business identity separate. A provider’s event identifier can help recognise repeated delivery, while an order reference can help stop two different routes creating the same dispatch request.
Shopify’s delivery documentation distinguishes duplicate deliveries from multiple subscriptions responding to the same merchant action. It also requires verification of HTTPS webhook signatures before processing. For a Shopify integration, ask the developer to explain both its duplicate-delivery check and its protection against two subscriptions triggering the same business action.
Protect against two runs arriving together
A simple “search for the record, then create it if missing” sequence can be vulnerable when two runs overlap. Both may search before either has created the record.
For a custom integration, our recommendation is an enforced uniqueness rule and a controlled way to claim work. PostgreSQL’s constraints documentation explains how a unique constraint enforces uniqueness across a column or combination of columns. Other databases and applications have their own mechanisms. Ask your developer what enforces the rule in your actual system.
A database constraint alone does not stop an external email or dispatch request being sent twice. The integration still needs to coordinate that external action and its completion record.
Record completion for each step
A workflow can be partially complete. Treating the whole run as either “done” or “failed” makes recovery harder when it crosses several systems.
We recommend retaining the status and destination reference for each important action. In the enquiry example, the contact and task references should remain available even if the email step needs attention. A person reviewing the exception can then see what remains to be done.
Stripe’s recovery guidance for undelivered events uses separate processing and processed states, and warns that manual recovery can overlap automatic redelivery. That supports a useful design principle: claim work before starting it and record completion after it succeeds. The implementation must also provide a recovery route for work left in progress after a crash.
For custom webhook handlers, ask how incoming work is safely retained before receipt is acknowledged. A fast acknowledgement should not conceal unfinished work that nobody can recover. Agree who owns the remaining queue or exception list.
Check what your platform’s replay button actually does
Replay behaviour is platform-specific. Do not assume a button labelled “retry” always resumes from exactly the point you expect.
Zapier’s replay documentation, updated in May 2026, distinguishes replaying errored actions from replaying an entire Zap. In its failed-action example, a successful email step is not repeated when a later spreadsheet step is replayed. An entire-run replay from the editor creates a new run and repeats every step, including previously successful ones.
The same guidance says Filter and Paths steps are not replayed during replay from Zap history. Autoreplay error notifications are delayed until the final attempt fails. These details matter when deciding whether a condition will be checked again and when someone will hear about a problem.
Before recovering a run, establish its replay scope, check the destination for completed actions and check whether an automatic attempt is already scheduled. Where the outcome is uncertain, use a documented review route rather than repeatedly pressing replay.
Separate outgoing request protection from incoming events
There are two directions to protect: notifications arriving at your integration, and requests your integration sends to another service.
Stripe’s API guidance on idempotent requests allows a supported outgoing request to be retried with the same idempotency key. Subsequent requests return the saved result, including a saved server error. Keys can be removed after they are at least 24 hours old, and reusing a key after removal can create a new request.
That is not a permanent duplicate-prevention record for your whole business workflow. Nor does an outgoing Stripe key protect an unrelated CRM or email action. Ask how each destination handles uncertain outcomes and how long your own operation history remains available for recovery.
Use a new operation identity for genuinely new work. Reusing the original identity should mean retrying that original action, not concealing a different order behind it.
Test the failures that matter to customers
Ask for these demonstrations in a test environment using dummy records and controlled destinations. Agree the expected business result before running them.
| Test | Expected outcome |
|---|---|
| Deliver the same notification twice | One intended business action, with the repeat recognised. |
| Deliver it twice at the same time | One action, despite overlapping runs. |
| Lose the response after the destination succeeds | Recovery establishes the existing result without blindly creating another. |
| Fail a later step after an earlier one succeeds | The unfinished work is recovered and completed work is preserved. |
| Send a genuine second order from the same customer | The new order proceeds normally. |
| Exhaust the available retries | A named person receives an actionable exception. |
Judge the result in the receiving systems as well as the automation history. A run marked successful is not enough if it created two dispatch requests. A recognised duplicate should be visible in the history without becoming another customer-facing action.
Give recovery a clear owner
Keep a short recovery procedure covering who checks exceptions, which reference to search, how to confirm completed work and when to escalate an uncertain outcome. Include a way to compare original orders or enquiries with destination records so missing work can be found too.
Start with the workflow where a duplicate would cause the most disruption. Fix that handover, prove the recovery path and apply the same discipline to the next integration. You do not need to replace every tool to make one unreliable connection safer.
BuzzBoost’s AI and automation service covers workflow handovers and failure handling. If duplicate emails, orders or CRM tasks are creating extra work, tell us which systems are involved. We can help identify the unreliable step and plan a practical repair.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
