Define what counts as the same action
Start with the business meaning of a duplicate. Two enquiries from one email address may be different requests, while two copies of the same supplier document may represent one transaction. Choose stable source identifiers where they exist and define the scope in which they are unique. Do not rely solely on a name, filename or date. Write examples of genuine duplicates and legitimate repeats so the implementation can be checked against both. A rule that blocks all repeats can lose valid work just as easily as no rule creates duplicates.
Keep an action record
Ask the implementation team how the workflow records an action as received, in progress, completed or failed. That record should include the source identifier and destination reference when available. A check performed only after writing is too late to prevent simultaneous duplicates. Two workers can both see that an item is absent and then both create it. The technical mechanism depends on the systems involved, but the business acceptance test is simple: send the same request concurrently and verify that only the intended action exists.
Treat uncertain outcomes carefully
If a request times out, the destination may have completed it even though the response was lost. Check for the original result before attempting another write. Where the destination supports a unique request key, verify how that feature behaves in the actual integration. Do not assume every connector exposes it. If the result cannot be established automatically, send the item to a review queue with its uncertain state clearly labelled. Avoid telling staff it failed when the real problem is that the outcome is not yet known.
Separate detection from deletion
Finding two similar records does not automatically authorise deleting one. They may have different downstream activity or represent a legitimate repeat. Define who reviews suspected duplicates and what evidence they need. A hypothetical duplicate service request might be linked to the original while preserving the later caller update. An already-issued document may need a different correction process. Keep the history rather than hiding the duplicate by silently removing evidence. The right repair depends on what has happened since creation, not only on matching fields.
Test retries and repeat customers
Test an exact repeated event, a simultaneous duplicate, an interrupted response and a legitimate new request from the same person. Include a corrected source document with the same reference so the system does not ignore a real amendment. Inspect the final destination records and outbound messages, not just workflow logs. A single business write may still have produced duplicate notifications. Record which actions were suppressed and why. The test should prove both that duplicates are controlled and that genuine new work can still proceed.
Make manual replay deliberate
Staff may need to replay a failed item after fixing an integration. Give them a controlled replay action that checks the previous state and records who requested it. Avoid telling people to copy a file into an intake folder repeatedly until something happens. Show whether the item completed, is waiting or needs review. Track repeated events as a diagnostic signal without presenting each as new business volume. Review the retention period for duplicate records so an older replay does not unexpectedly become eligible for execution again.