It stops, and that isn't the problem
If the connection drops while an automation is working, the automation breaks off, exactly the way the person filling in that screen would have broken off, and so far nothing serious has happened
The trouble comes afterwards, when the line comes back and the work has to start again, because at that point there is only one question, how far had it got before it went down
If nobody knows exactly, there are two roads and both are bad. Either you redo it from the start, and some entries end up in there twice, or you pick up further along to be safe, and something doesn't get recorded at all
The duplicate is the real nightmare, because it makes no noise. An invoice recorded twice throws no error on screen, you find it when the books don't add up, and by then a payment may already have gone out
A memory of what has already been done
The answer isn't to make the automation immune to the line going down, no program is. The answer is that the system keeps track of every case as it closes it
It works like this. Before recording an invoice the system notes that it is about to, and once it has recorded it, it notes that the job is done. So when it starts again it finds the cases in three states, the closed ones, which it skips, the ones never started, which it works through, and the ones left halfway, which are the only ones that deserve attention
The halfway ones get the most cautious rule there is. Before writing them again it goes and looks in your business software to see whether the document is already there, and if that check isn't possible or comes back unclear the system doesn't guess, it stops and leaves the case on a list for a person
This is the same reasoning that holds up the checks and stops in an automation in general. Stopping costs a few minutes of somebody's time, guessing costs a great deal more
You avoid duplicates by design, not by hand
There is a wrong way to settle this, and it's saying that somebody will check afterwards anyway. That somebody checks for the first month and then stops, and manual checks for duplicates are exactly the kind of dull work people skip when they're in a hurry
The right road is for the duplicate to be impossible because of the way the system is built, not unlikely thanks to the goodwill of whoever is watching. You get there by deciding up front what makes a case unique, usually the document number and date together with the supplier, and by running that check before every write, always, even when the line never went down
The duplicate check earns its keep even when the internet is working perfectly, because the same invoice can arrive twice in the post, and one person can record something a colleague had already recorded that morning
Not every automation needs the network in the same way. One that works on a program installed in the office suffers far less than one that has to log into a web portal, and that feeds into the choice of where to run the system