Reliable automations retry failed work. Unreliable automations retry failed work and accidentally create a second lead, send the same email twice or charge the same action twice.
The difference is often idempotency: designing an operation so repeating the same request does not create a second unintended side effect.
Why retries are unavoidable
Networks time out. APIs return temporary errors. A workflow may send a request successfully but fail to receive the response, leaving it uncertain whether the action happened. Simply “never retry” turns transient problems into lost work.
The safer pattern is to retry with enough identity that the receiving system can recognize the operation as the same logical action.
Give each business action a stable key
An idempotency key should represent the operation, not the attempt. If one form submission should create one CRM lead, generate a stable identifier for that submission and reuse it across retries. Do not create a new key every time the network call is repeated.
Payment APIs have made this pattern familiar; Stripe’s idempotent request documentation is a clear public example of using a key to make retries safer.
Do not confuse duplicate detection with fuzzy matching
Checking whether “a similar lead” already exists is useful, but it is not the same as idempotency. Names and email subjects can change. Two legitimate customers can share details. A stable request or event identifier is much stronger than trying to infer whether two records look alike after the fact.
Protect the side effect, not just the AI step
An AI classifier may safely run twice if it only produces a temporary result. The dangerous step is usually the external effect: creating a record, sending a message, updating status or triggering billing.
Place idempotency around those irreversible or user-visible actions. That complements the retry strategy described in our automation error-handling guide.
Store completion state deliberately
For workflows you control, keep a record of the operation key and its outcome. Before repeating the side effect, ask whether that key already completed successfully. If it did, return the prior result or continue from the next safe step.
Be careful with partial completion. A workflow may create the CRM record successfully and fail before sending the acknowledgement. The recovery path should know which step completed rather than rerun the whole chain blindly.
Use step-level identifiers for multi-action workflows
A single run may legitimately perform several actions. One overall run ID is useful for traceability, but each side effect may need its own idempotency scope. For example:
lead-create:{submission_id}welcome-email:{submission_id}sales-task:{submission_id}
That lets the workflow retry the missing email without trying to recreate the lead.
Handle concurrent runs
Duplicate work is not caused only by retries. Two workers can receive the same event at nearly the same time. A simple “check then create” sequence may still race. For important workflows, use atomic database constraints, transactional writes or provider-supported idempotency rather than relying only on a pre-check.
Audit keys and outcomes
Log the workflow run ID, idempotency key, action, target record and final result. This makes it possible to explain why a retry was skipped or why two operations were considered different.
Our article on AI automation audit logs covers the wider traceability model, while our CRM and follow-up automation service applies these controls to real lead workflows.
Examples of where idempotency matters
- form submission to CRM;
- CRM stage change to email sequence;
- meeting transcript to task creation;
- document intake to case record;
- webhook to fulfillment request;
- AI approval to customer message.
Reliable automation assumes failure will happen
Retries are not a sign of bad engineering; unbounded, context-free retries are. Design each important side effect so the system can answer, “Have I already completed this exact business action?”
Once that answer is dependable, temporary failures become recoverable events rather than duplicate customer experiences.