Imagine your morning report arrives at 8 am, as usual. The automated process shows a green tick, but the figures look familiar.
The source file never arrived. The process used yesterday's data and sent the report on time. Every step completed, yet the report is wrong for today's meeting.
This is why a useful automation needs a definition of success that goes beyond "it ran".
Make "ready" mean something
For a scheduled report, the process could check the reporting date inside the source file before using it. Checking that a file exists would miss the problem in our example.
The business also needs to decide whether an incomplete report is useful. A manager might prefer figures from two sites with a clear warning that the third is missing. Another report may need to wait until every site has submitted.
The automated process needs to follow that decision and show readers what is missing.
What can go wrong between steps
Different failures need different responses. Each example below explains why.
The file arrives late
A missing file may mean the source system is delayed, rather than that there was no activity to report. Treating an absent submission as zero would hide that difference. The report needs to show the missing submission or wait for it, according to the agreed rule.
The same item arrives twice
If an invoice arrives twice, the process needs a way to recognise the original. A reference that identifies each invoice helps distinguish a repeated delivery from a new invoice. The receiving system also needs to prevent that repeated delivery from creating a second record.
A system stops responding
A request to retrieve data may be safe to repeat after a short wait. Creating an invoice needs more care. The system may have created it before the connection failed, leaving the sender without confirmation. Repeating that request without checking the outcome could create a duplicate.
Some failures need a person
Trying again can resolve a temporary connection problem. It cannot decide whether an unexpected total is correct. That may need someone who understands the underlying records.
Repeated attempts need a limit and a person responsible for unresolved failures. An alert should identify the affected item and the last confirmed step. Otherwise, the person receiving it has to reconstruct the problem before making a decision.
If an automated process stops, the person responsible needs to know where it stopped and why.
Recovery needs testing too
A recovery process needs to account for work completed before a failure. Returning the connection to normal does not tell you which requests reached the other system.
Testing what happens when a connection fails just after an invoice is created can reveal a problem that a successful run never exposes. The useful question is whether recovery leaves you with one correct invoice and a clear record of what happened.
For a technical explanation of safe retries and their limits, see Microsoft's retry pattern guidance.