Prevent duplicate writes in Make with stable keys and recovery states

Define the event and action keys

A customer ID identifies the person; an intake ID identifies this request. Separate action keys when storage and notification need independent recovery, such as formA|response123|save and formA|response123|notify. A fresh random value or receipt timestamp on every attempt cannot identify a repeated delivery of the same source event. Choose a key that survives retries and is scoped to its source.

Keep enough state to recover partial work

Use states that describe actual milestones, such as received, saved, notified and needs_review. Preserve returned record and message identifiers. If storage succeeds and notification fails, recovery starts from evidence of saved work. A single completed flag cannot tell an operator which effect already happened or whether retrying it would create another record.

Use a Data store as an operational ledger

Create a dedicated Data store and keep the action key alongside state and external identifiers. Record-existence checks can direct the workflow to a recovery path. Do not treat an unconditional add-or-replace as proof that only one worker processed an event: overwriting a key can erase useful evidence. Explicitly test how an already existing key is handled before relying on the ledger.

Recognize the search-then-insert race

Two concurrent runs can both observe “not found” and both write. Ordering one scenario’s runs may reduce that race, but does not serialize other scenarios or external writers. A strict requirement needs enforcement at the destination, an atomic claim or a supported idempotency key. Decide what level of duplicate risk the business accepts instead of describing a lookup as a transactional guarantee.

Resolve ambiguous outcomes before repeating an effect

A destination can accept a write even when the caller times out before receiving confirmation. Search the destination using the event reference or returned identifier before replaying. If the effect exists, reconcile the state; if the result remains uncertain, route it to review. This is especially important for charges and important notifications, where another attempt can have a real cost.

Test more than one repeated input

Test a repeated event, a different event from the same customer, concurrent duplicates, failure after storage and failure after notification before its state update. Check the mapping of source IDs to destination IDs as well as row counts. Dropping the customer’s legitimate second request is a data-loss bug, not successful deduplication. Keep the expected result for every sample.

Common question: should a completed key be written first?

Writing a completed key before the work can lose a request if the later operation fails: a redelivery now looks finished. Writing only after the work leaves a window between the external effect and its saved evidence. Neither ordering alone solves the problem. Design a processing state, timeout and reconciliation path.

For an important effect, prefer an idempotency facility or unique constraint enforced by its destination. When storage and notification are different services, track their results separately. Make long-running or stale processing records visible to an operator instead of treating every existing key as permanent success.

Maintain the ledger for the replay window

Deleting a key can make an old replay look new. Choose a retention period that covers the expected redelivery and repair window. This does not require retaining entire personal payloads indefinitely. Keep the minimal identifiers, states and times needed for reconciliation, and assign someone to review unresolved records so the ledger does not become a forgotten queue.

• Handle Make errors: execution history, incomplete runs and safe retries
• Log selected Gmail messages to Google Sheets with Make
• Send spreadsheet deadline reminders with Make without daily duplicates