A workflow receives an event and creates a task. Then the same event arrives again. Should it create another task?
The answer seems obvious until the automation is running and someone has to determine which work is real. Reliable integrations need a clear distinction between a repeated delivery and a new business event.
Stripe's webhook documentation is one concrete example: it describes retries, possible duplicate events, and the absence of a guaranteed event order. Those details are specific to Stripe's documented behavior; other providers need their own review. Source: Stripe
Name the action that must not repeat
For a hypothetical order workflow, receiving an event twice should not automatically mean preparing two shipments. The system needs a durable way to recognize the event or business action and decide whether it has already been handled.
This principle is often called idempotency: repeating an operation should not create an additional unintended effect. The implementation depends on the workflow. Checking a temporary in-memory flag is different from preserving state across a restart.
Also distinguish “received” from “completed.” A process can record an event and then fail before finishing the work. Marking it done too early can lose the task; retrying without checking the result can repeat it.
Make recovery part of the interface
Operators should be able to see failed work, understand what completed, and retry safely. A useful error view identifies the affected record and next action without exposing unnecessary sensitive information.
Test the uncomfortable sequence: event received, downstream action succeeds, acknowledgment fails, event arrives again. Also test events arriving in an unexpected order. The appropriate response may be to fetch the current source record rather than treating every incoming message as a complete picture.
These details are not glamorous, but they determine whether automation removes work or creates cleanup.
Before approving an integration, ask the team to demonstrate a duplicate, a partial failure, and a recovery. A successful happy-path demonstration tells you the connection works. These tests tell you whether the business can live with it.