Prevent duplicate records before an automation goes live

Treat delivery and business intent as different things

An automation may receive the same event more than once because a sender retries, a connection drops after the destination committed, or a person presses the button again. The transport event can be duplicated even when the business intent is singular: create one invoice, one task, or one welcome message.

Stripe's API documentation describes the core pattern: a client sends an idempotency key, and later requests with that key receive the saved result rather than performing the operation again. AWS Powertools documents a similar pattern with a persisted record whose status can be in progress, complete, or expired. Both sources also expose the limitation: the key and its retention window have to represent the business operation correctly.

Choose a key from the event's identity

Prefer an immutable source event ID supplied by the originating system. If none exists, construct a business key from fields that should uniquely identify the action, such as order_id + action_type. Do not use an email address or other sensitive value as a key when a random or opaque identifier will do. Do not use a timestamp alone; two deliveries of the same event will usually have different receipt times.

A content hash can help detect repeated payloads, but it is not always a business identity. Two legitimate orders can have identical fields. Conversely, a repeat delivery can contain a harmless metadata change. Make the rule explicit.

Reserve before the side effect

1. Receive the event and validate required fields.
2. Attempt to create an idempotency record with a uniqueness constraint.
3. If the record is new, mark it in progress and perform the side effect.
4. Store the destination record ID and final status.
5. If the key already exists, return or reuse the recorded result instead of creating another output.

The reservation closes the race where two workers check, both see nothing, and both create a record. AWS's documentation describes locking concurrent identical requests while one invocation is in progress. If your no-code platform cannot reserve atomically, put the uniqueness constraint in the destination or route creates through a small service that can.

Do not silently merge conflicting intent

If the same key arrives with materially different fields, stop and flag it. Stripe says it compares incoming parameters with the original request to prevent accidental key reuse. For a business workflow, store a compact payload fingerprint or the important fields beside the key. A changed amount, recipient, project, or action type belongs in an exception queue, not under an old success result.

Set retention from the replay horizon and business risk. Expiring a key too soon permits an old event to create a new side effect; retaining every key forever adds storage and privacy burden. Document the window and test a replay just inside and just outside it. Pair this guide with bounded retries and an exception queue and a stop switch. Duplicate prevention is complete only when the destination record can be traced back to the source key.