An automation can lose contact with another system after that system has already completed the requested action. Repeating the action without checking can create two tasks, two customer records or two messages. Before enabling automatic retries, define how the business will recognize one intended operation, determine its outcome and handle uncertainty without silently multiplying work.
Distinguish Failure From An Unknown Outcome
AWS’s guidance explains that a timeout does not necessarily mean an action failed to occur, and that retries can add load to a struggling service. For an owner, the practical distinction is between a confirmed rejection and an outcome the integration could not observe. These states need different recovery paths.
Ask the implementer to show where the workflow stores the intended action and the destination’s response or reference. A generic “failed” label is insufficient if it hides whether a customer message was accepted or a task was created. Staff need a way to reconcile uncertain actions before manually repeating them.
Give One Intended Operation A Stable Identity
Use an operation identifier that survives a retry. Where a destination supports idempotency, repeated requests with the same valid identifier can be handled as the same intended action under that API’s documented rules. Stripe’s documentation illustrates this mechanism and also describes limits and differing behavior across API versions. Do not assume every integration provides identical protection.
The identifier should describe the operation internally without embedding sensitive customer information. Changing it on every attempt defeats the purpose. A genuinely new request needs a new identity, while retrying the same work should preserve the original one. Ask how changes in the request’s contents are detected rather than silently replayed under an old identity.
Reconcile A Concrete Duplicate Scenario
Illustrative scenario: an onboarding workflow asks a project system to create a task. The task is created, but the response never reaches the workflow. A naive retry creates another task. In a safer design, the workflow retains its operation reference and either uses supported destination deduplication or checks a reliable destination reference before deciding what to do next.
If the destination cannot provide a dependable way to identify completed work, use an explicit uncertain state and a staff review path. Do not claim exactly-once execution merely because the automation tool has a retry checkbox. The appropriate control depends on what the receiving system can actually confirm.
Bound Retries And Make Exceptions Visible
AWS describes increasing delays between retries, spreading retry timing and limiting attempts to avoid magnifying overload. Have the technical owner choose the policy using the destination’s current behavior and documentation. An invalid business request usually needs correction, while a transient connection problem may merit another attempt.
Define who owns an action after automatic recovery stops. Give that person a concise record of the operation, status and safe next action, without exposing unnecessary payload data. Prevent a manual operator and an automatic retry from both completing the same work. The exception queue is part of the workflow’s design, not an afterthought for occasional failures.
Test Recovery Before Increasing Volume
In a controlled environment, exercise a rejection, a lost response after completion, repeated delivery and interruption during recovery. Verify the destination’s actual records as well as the automation’s status screen. Count business actions, not just successful network responses. Check that the same operation can be reconciled after a restart.
Agree on a stopping threshold for unresolved work and a method for pausing the workflow without losing its pending records. Review exception age and duplicate outcomes after release. The goal is dependable completion with visible uncertainty, rather than a dashboard that turns every retry green while staff repair duplicate work elsewhere.
Common Questions
Can We Just Turn Retries Off?
That can prevent some repeated actions but leave transient failures unresolved. The right decision depends on the action’s consequences and the destination’s capabilities. Provide a controlled recovery path either way.
Does An Idempotency Key Protect Every Step?
No. Its protection is limited to the system and operation that implement it. A multi-step workflow needs explicit handling for each consequential action and for failures between steps.
Sources And Further Reading
- AWS: Timeouts, Retries, And Backoff With Jitter · Checked 2026-10-26
- Stripe: Idempotent Requests · Checked 2026-10-26
These sources provide context. Requirements depend on the actual activity and applicable jurisdiction. Business-process guidance does not replace professional advice.