An automation creates a customer record, but the receiving system's reply never arrives. The workflow retries and creates another record. From the automation's perspective, repeating the request may seem like a sensible recovery step. From the business's perspective, it has produced duplicate contacts, conflicting tasks or two messages for the same enquiry.
The difficult part is that a missing acknowledgement does not tell you whether the first operation happened. Reliable automation needs a way to recognise the same intended operation across repeated attempts. This is where idempotency, stable identifiers and destination controls become useful.
You do not need to understand every implementation detail to brief this properly. You do need to distinguish a retry from a new business event, ask how duplicates are prevented and test what happens when the workflow stops between important steps.
Define the business operation that must happen once
Start with a specific task, such as creating one CRM enquiry from one website submission. Identify the source event, the record to create and any follow-up actions. “Avoid duplicates” is too broad unless the team agrees what counts as the same operation.
Two enquiries from the same email address are not necessarily duplicates. A customer may submit separate requests for different projects. Conversely, the same submission can arrive through several delivery attempts. The workflow must preserve legitimate repeat business while recognising repeated processing of one event.
Agree an operation identifier that remains stable across retries. A submission or event identifier can be suitable when its scope and uniqueness are understood. Record where it originates, how it is passed through the workflow and how long the receiving system can recognise it.
Keep the identifier separate from sensitive content. A key should identify the operation without needing to expose a customer's email address or the whole message. Also clarify whether an edit to an enquiry is a new operation or another attempt at the original one.
Understand idempotency through a practical example
In this context, an idempotent operation can be repeated without producing another business effect. The first attempt creates the intended record; a recognised retry refers to that same operation rather than creating an additional record.
An idempotency key can allow a repeated request to return a stored result instead of repeating the operation. Availability, retention and error behaviour depend on the actual API. Verify the chosen CRM or automation service's contract rather than assuming identical rules. Our idempotency and retry guide provides the related checks.
Ask the destination supplier whether it supports idempotent creation and how that support works. Check the key's scope, retention, parameter handling and concurrent-request behaviour. The answer should describe the actual endpoint the workflow uses, rather than a general claim that the platform prevents duplicates.
Use the same operation key for the same logical retry. Generating a fresh key on every attempt can make each request look new to the destination. However, reusing a key for a genuinely different event can suppress legitimate work. The mapping needs to be deliberate.
Check what happens when native support is absent
Some systems allow a unique external reference on a record. That can provide a useful boundary if the destination enforces uniqueness correctly. The workflow can associate a source submission with the destination record and recognise an attempted repeat.
A separate processing register may also help track received events and their status. It should distinguish work received, work in progress, successful completion and cases needing investigation. Recording only “started” can leave the business unable to tell whether the destination action happened.
A simple search followed by creation is not always sufficient. Two workers can both search before either has created the record, then both proceed. Ask the developer how the implementation handles this race, using an appropriate destination constraint or atomic coordination where available.
Avoid promises of universal exactly-once execution across independent systems. If the workflow cannot establish a protected creation boundary, document the limitation and add reconciliation and human review. The business needs an honest account of the remaining ambiguity.
Separate record creation from later side effects
A workflow may create the CRM record, assign a task and send a confirmation message. Preventing a duplicate record does not automatically prevent a duplicate email. Each meaningful side effect needs a clear operation boundary and recovery rule.
Map the sequence and record the evidence available after each step. If record creation succeeds, but task assignment fails, the next attempt should continue appropriately rather than recreate everything. A useful implementation can recognise completed work and resume from the unresolved operation.
Do not treat a local success flag as proof that another system completed its action. Where possible, retain the destination's record identifier and response. If acknowledgement is ambiguous, inspect the destination or place the case in a review queue before repeating a consequential action blindly.
Keep follow-up behaviour consistent with the customer journey. A visitor should not receive contradictory confirmations because the internal workflow took two different recovery paths. Review the messages alongside the technical sequence.
Define retries that help recovery
Classify failures before retrying. A temporary connection problem may justify another attempt. Invalid data or a permissions error usually needs correction. Repeating the same malformed request many times creates noise and can make the original problem harder to investigate.
Use bounded retry rules with appropriate delays and a clear stopping point. Ask how the platform handles rate limits and destination availability. The business should know what happens after the last attempt and who receives the unresolved case.
Preserve the original event and operation identifier during recovery. Manual replay should follow the same duplicate-prevention rules as automatic retry. An administrator pressing “run again” should not accidentally bypass the control that protects normal processing.
Record enough information to investigate without collecting unnecessary customer content. Useful operational evidence includes the event identifier, action, time, destination identifier and outcome. Choose access and retention according to the information involved and the organisation's agreed handling rules.
Test interruption points and simultaneous attempts
Build a test matrix around the places the workflow can stop. Test failure before creation, failure after creation but before acknowledgement, failure between creation and notification, and replay after a completed run. Check the destination records and messages after each case.
Include simultaneous attempts for the same event in an appropriate test environment. This tests the protection against concurrent processing rather than only sequential repeats. Also test two genuinely different events from the same customer to make sure legitimate work is retained.
Inspect what happens when the duplicate-recognition period has expired or a record has been changed or removed. These cases may need a defined operational policy. The team should not discover the rules for old replays during a live incident.
Agree an expected outcome for every test. Count the records and side effects, inspect their identifiers and confirm that unresolved cases are visible. A green execution log is insufficient if the receiving system contains two records.
Use reconciliation to maintain confidence
Compare source events with destination outcomes over a suitable period. Look for missing events, repeated external references and unexplained mismatches. Reconciliation can reveal faults that individual workflow runs report as successful.
Give the review process an owner and a practical correction route. A suspected duplicate should be investigated before records are merged or removed, especially when they contain separate customer activity. Keep the link to the originating event, so the decision can be checked.
Giraffe Digital's digital strategy service considers tools and customer journeys together. Defining duplicate prevention around actual business operations helps an automation recover predictably and keeps its outputs useful to the people who rely on them.
Frequently asked questions
How should we define the business operation that must happen once?
Start with a specific task, such as creating one CRM enquiry from one website submission. Identify the source event, the record to create and any follow-up actions. "Avoid duplicates" is too broad unless the team agrees what counts as the same operation. Two enquiries from the same email address are not necessarily duplicates. A customer may submit separate requests for different projects. Conversely, the same submission can arrive through several delivery attempts. The workflow must preserve legitimate repeat business while recognising repeated processing of one event. Agree an operation identifier that remains stable across retries. A submission or event identifier can be suitable when its scope and uniqueness are understood. Record where it originates, how it is passed through the workflow and how long the receiving system can recognise it.
How should we check what happens when native support is absent?
Some systems allow a unique external reference on a record. That can provide a useful boundary if the destination enforces uniqueness correctly. The workflow can associate a source submission with the destination record and recognise an attempted repeat. A separate processing register may also help track received events and their status. It should distinguish work received, work in progress, successful completion and cases needing investigation. Recording only "started" can leave the business unable to tell whether the destination action happened. A simple search followed by creation is not always sufficient. Two workers can both search before either has created the record, then both proceed. Ask the developer how the implementation handles this race, using an appropriate destination constraint or atomic coordination where available.
How should we separate record creation from later side effects?
A workflow may create the CRM record, assign a task and send a confirmation message. Preventing a duplicate record does not automatically prevent a duplicate email. Each meaningful side effect needs a clear operation boundary and recovery rule. Map the sequence and record the evidence available after each step. If record creation succeeds, but task assignment fails, the next attempt should continue appropriately rather than recreate everything. A useful implementation can recognise completed work and resume from the unresolved operation. Do not treat a local success flag as proof that another system completed its action. Where possible, retain the destination's record identifier and response. If acknowledgement is ambiguous, inspect the destination or place the case in a review queue before repeating a consequential action blindly.
How should we define retries that help recovery?
Classify failures before retrying. A temporary connection problem may justify another attempt. Invalid data or a permissions error usually needs correction. Repeating the same malformed request many times creates noise and can make the original problem harder to investigate. Use bounded retry rules with appropriate delays and a clear stopping point. Ask how the platform handles rate limits and destination availability. The business should know what happens after the last attempt and who receives the unresolved case. Preserve the original event and operation identifier during recovery. Manual replay should follow the same duplicate-prevention rules as automatic retry. An administrator pressing "run again" should not accidentally bypass the control that protects normal processing. Record enough information to investigate without collecting unnecessary customer content.
How should we use reconciliation to maintain confidence?
Compare source events with destination outcomes over a suitable period. Look for missing events, repeated external references and unexplained mismatches. Reconciliation can reveal faults that individual workflow runs report as successful. Give the review process an owner and a practical correction route. A suspected duplicate should be investigated before records are merged or removed, especially when they contain separate customer activity. Keep the link to the originating event, so the decision can be checked. Giraffe Digital's digital strategy service considers tools and customer journeys together. Defining duplicate prevention around actual business operations helps an automation recover predictably and keeps its outputs useful to the people who rely on them.
