An integration is useful when the business can trust what happened, including when a destination is slow, a request is repeated or a record is rejected. A successful demo proves one path through the system. It does not settle how the operation will recover.
Define the business event first
Consider a fictional order-to-invoice flow. “Send the order” is incomplete: which approval allows it to move, which system owns the customer and price, and which identifier will connect the source order to its destination record? Finance needs an answer about the record, not simply a green status beside an HTTP request.
A useful assessment traces one real operating flow and records its boundaries. Interview the process owner and the people who handle exceptions. Distinguish information that must arrive immediately from information that can wait until an agreed reconciliation.
Make repeated delivery safe
One source event may be delivered more than once. A timeout also leaves an uncomfortable question: did the destination complete the action before the response was lost? Retrying without checking can turn a temporary communication problem into duplicate business work.
Decide how an operation is identified, how the destination treats a repeated request and how conflicting requests are detected. AWS’s discussion of idempotent APIs provides a detailed treatment of safe retry semantics. The design must fit the actual receiving interface; an identifier alone does not prove that a vendor supports duplicate protection.
Give failures an owner
For the fictional flow, an invalid finance field should become an actionable exception. Record the affected source identifier, a useful reason, the stage reached and who can resolve it. Avoid putting unnecessary personal information or credentials into the diagnostic record.
Then test the uncomfortable paths: repeat the event, interrupt the destination, reject a field and lose a response. Ask an authorised operator to demonstrate recovery. A retry policy is only part of that procedure; unresolved business records still need reconciliation and ownership.
Measure the operating change
Before implementation, agree what matters: repeated capture effort, missing records, duplicate actions or the time an exception remains unresolved. Record the measurement window and other changes that could affect the result. The first target should be a controlled, observable flow, rather than an unsupported claim of seamless integration.
Experience and a useful next step
The EmailCraft AI delivery example describes product and integration recovery with bounded functionality claims; it is not an ERP benchmark. An Integration Assessment can define one priority flow, the available interfaces and a recovery model before a separate implementation commitment.