Operations Automation Retries: Handling Duplicate Actions

Why a timeout needs a different response

An automation retry repeats an attempted step after an interruption or error. Before repeating a step that changes another system, check whether the original action succeeded. A missing response does not mean nothing happened.

Consider a hypothetical intake workflow that creates a CRM task, then notifies its owner. The CRM accepts the task, but the response fails to reach the workflow. If the workflow starts again without checking the result, it may create a duplicate task. This example describes a design risk, not a client incident.

The Amazon Builders' Library guide to idempotent APIs explains how request identifiers can help a service recognize repeated attempts without adding side effects. Whether a particular connector supports that behavior needs checking before you rely on it.

Decide what counts as the same action

Write down the business action before choosing a duplicate check. Creating a task for an incoming request differs from creating a new task after that request changes. Matching only the contact name would blur those intentions.

Specify which source event and action belong together. Keep that identity when retrying the same attempt. Treat a genuinely new instruction as a separate action, even when its text resembles an earlier request.

Ask the implementer where this identifier lives, how the receiving system uses it, and how long that system remembers it. An identifier recorded only in your workflow log does not establish that the destination will reject a duplicate.

Separate completed steps from uncertain ones

Design the run record so an operator can distinguish a step that has not started from a completed step or an attempt whose result is unknown. Record the destination's task identifier when it is available.

In the intake example, a failed notification should not automatically trigger another task creation. Give the notification its own recorded status and retry decision. If task creation has an unknown result, check the destination before proceeding or send the item for review when verification is unavailable.

For broader review-queue design, see AI workflow exception handling.

Decide when an operator should take over

A retry policy needs a stopping point. Ask the workflow owner to define which errors may be retried and which require correction. A missing required field needs attention to the input; repeating the unchanged request does not supply it.

Show the operator the original request and attempted action, along with any response from the destination. Include a clear reason for the pause. Avoid a generic failed status that leaves them guessing whether it is safe to restart.

If an operator completes the action manually, provide a way to record that decision before resuming the workflow. Otherwise the next automated attempt may repeat their work. The approval workflow guide covers the ownership decisions that sit around these steps.

Test interruptions around the write

Use synthetic records to rehearse failures at specific points:

• Interrupt the request before the destination accepts it.
• Let the destination accept the action, then withhold the response from the test workflow.
• Deliver the same source event again while the original run is still in progress.
• Fail a later notification after task creation succeeds.
• Resume a paused run after an operator records manual completion.

For each case, inspect the destination and the run record. A successful status on the workflow screen is not enough to show whether a duplicate task exists.

What should an automation retry brief include?

Document the intended action, how repeated attempts are identified, and the evidence needed to mark the action complete. Specify the route for unknown outcomes and who may resume a paused run. Include the destination's documented limits rather than assuming a connector supports duplicate protection.

Bring a worked interruption scenario to the implementation review. Ask the team to show what the operator would see and what the destination would contain after recovery.

For the post-launch side of the same workflow, see the automation monitoring guide.