Automation reruns create duplicate records: how do you define business keys and idempotency?
For duplicate automation records, define a stable key per business event and inspect trigger replay, retries and concurrent creation. Lookup-then-create can still race without atomicity.
Start troubleshooting here
For duplicate automation records, define a stable key per business event and inspect trigger replay, retries and concurrent creation. Lookup-then-create can still race without atomicity. Persist deduplication state and use supported uniqueness or idempotency mechanisms, verifying one intended record instead of hiding duplicate rows.
Define one intended result per business event
This applies to scheduled reruns, repeated form notifications and retries after create timeouts. Preserve event IDs and target records and define replay scope separately from genuinely new events. Names and titles can repeat across distinct business items and are poor universal keys. Fresh timestamps on each attempt cannot identify the same replay.
Inspect replay triggers and lookup-create races
Trace triggers and creates and check interruption after creation but before recording deduplication. Determine whether concurrent tasks both observed absence and then created. In-memory sets do not survive restarts. Multi-step external actions can partly complete, so the whole workflow is not always safely repeatable pure computation.
Persist business keys and use supported uniqueness constraints
Choose stable event IDs or business-defined composite keys and preserve associations before first action, with supported target-side uniqueness or idempotency. Read existing outcomes on conflict instead of overwriting different content blindly. Record step states for partial work and resume from confirmed progress. Do not delete all destination data and rerun as a repair.
Verify replay, concurrency and response-loss outcomes
In an authorized test environment, replay events and test concurrency and lost create responses, checking count and key correspondence. Submit a genuinely new event and verify it is not suppressed. Success needs both no duplication and no lost legitimate tasks. Normal workflow completion and filtered duplicate views do not establish underlying correctness.
This article reran no real workflow or deleted duplicates. Confirm target capabilities and key retention; SQLite syntax is not a third-party spreadsheet API. Existing duplicates require business review and merging rules. Designing deduplication does not authorize historical deletion or guarantee exactly-once execution across systems.
Checked sources
These sources support the concepts and methods described here. Examples and test scope are labeled separately; check the version of the tools you use.