When a connection briefly drops, automation may retry the request. That sounds like the right solution. But what if the first attempt actually succeeded and only the response was lost? When retrieving a list, nobody might even notice. But with a purchase order, invoice, or warehouse stock dispatch, a second successful attempt is hardly a reason to celebrate.
An application that sends approved purchase orders to an ERP system can encounter a subtle complication. A user clicks a button, waits for a moment, and eventually receives a message that the operation could not be confirmed. They try again. Meanwhile, the automation also retries the same operation in an attempt to help. Despite everyone’s good intentions, two requests may be created for a single actual purchase order.
Situations like these do not require disabling all retries. Temporary service unavailability should not mean that someone has to take over the process manually every time. However, we need to distinguish between operations that can be safely repeated and those that must not be executed twice. The reliability of integrations depends on precisely these details.
A Missing Response Does Not Mean a Missing Result
Two connected applications do not always have the same view of what happened. The receiving system may have saved the record while the sending system has already timed out. From the sender’s perspective, the operation failed. From the database’s perspective, it was completed. A repeated request can then create another record if the solution was not designed to handle this possibility.
A unique identifier for each transaction, which remains unchanged across retries, helps prevent this problem. Detecting business-level duplicates is a separate task. An invoice received from a different email address or with a different attachment name may still be the same document. Technical retries and resubmitted business documents therefore require related, but not identical, rules.
Validation Should Happen Close to the Actual Database Write
Simply asking “Does this record already exist?” may not be enough. Two concurrent processes can both receive a response indicating that the record does not exist and then both create it. That is why it is important to use the capabilities of the target system, such as unique keys or built-in support for safely repeating requests through its interface.
If the target application does not provide such capabilities, the integration needs another way to manage requests and verify their results. Sometimes a queue helps; in other cases, a subsequent verification using an agreed identifier is more appropriate. There is no single universal checkbox that solves every combination of services.
For users, the outcome should not be a mystery. They need to distinguish between a rejected request, a request that is still being processed, and a situation where the result is awaiting verification. Only then can they safely decide whether to wait, correct the input, or ask support for assistance.
Reliability Must Also Be Tested Under Unfavorable Timing Conditions
When testing an integration, it makes sense to resend the same message, initiate two requests simultaneously, and interrupt communication after a database write has been completed. These are not resilience tests for their own sake. They reveal how the system behaves in situations that a typical successful demonstration would never expose.
Handling ambiguous cases is equally important. A history of transactions, responses from the receiving system, and related identifiers make it possible to trace the outcome without manually searching through multiple applications. When automation requires human assistance, it should provide useful information rather than simply displaying a generic red error message.
For a business, the result is greater confidence that a technical problem will not create a new business problem. Automatic retries then genuinely save work instead of creating additional duplicate-cleanup tasks. And that is the measure that matters to us at Evenaut: not how many times a flow completed successfully, but whether it correctly accomplished the task it was designed to perform.
Integrating business applications and want to keep data transfers under control? Contact us at customers@evenaut.com.
