Identify where a duplicate can occur
A trigger may be delivered again, a user may start another run, or an earlier attempt may time out before its result is visible. If the workflow sends messages, creates records, or updates another service, a second run can repeat those effects. Map which steps change external state before deciding how to handle repeats.
Use a stable business identifier already associated with the event, such as an order or request reference, to look up existing work before creating it again. Do not treat a temporary run identifier as a durable business key unless the system explicitly guarantees that behavior.
Test repeated and delayed events
Run a controlled test with the same event twice and confirm the second attempt does not create an unintended duplicate. Also test delayed arrival and a failure after an external action has succeeded but before the workflow records its result.
Record the event reference and outcome so operators can distinguish a replay from new work. If a duplicate does occur, stop further retries and reconcile the external system before manually correcting data. Design the recovery path deliberately instead of assuming every trigger is delivered exactly once.