Delivery Verification & Failure Recovery
Define success at each stage of a workflow. A file can arrive in Files.com, pass a validation, transfer to a partner, and still fail when the partner imports it. Those are separate outcomes with different evidence and different people responsible for responding.
Follow the Evidence
Start with the failed business result and work backward through the file journey. Use the filename, path, delivery time, and available run identifiers to correlate records. Unique delivery filenames or business identifiers make this easier than repeatedly overwriting latest.csv.
| Question | Evidence to inspect |
|---|---|
| Did Files.com receive the input? | File history and the incoming transfer's records |
| Did the expected work run? | Automation or Sync run status and per-file results |
| Did processing succeed? | The processing feature's result, output file, and validation records |
| Did the remote transfer complete? | Outbound request or Sync transfer records and, when available, destination records |
| Did the recipient accept the business data? | An acknowledgment or import result from the receiving application |
For a mounted destination using buffered uploads, the incoming upload can complete before onward delivery to the Remote Server. A notification about the incoming file does not replace verification of that onward transfer.
Detect Missing Work
A failed run produces an error. A file that never arrives might produce no run at all. Use Expectations to monitor the deliveries that should occur, including their timing and supported content checks.
Use Event Channels to route selected operational events to the team or system that responds. Check the channel's delivery attempts separately from the event it reports. A webhook target accepting a notification does not prove someone investigated it.
Assign responsibility for a missing input, a failed transfer, and a rejected import. They may belong to the supplier, your transfer team, and the receiving application's owner respectively.
Understand the Retry Boundary
Sync error handling retries failures, and later scheduled runs independently compare the current source and destination. A partial failure means some files transferred and others did not. Inspect individual failures before treating the whole run as undelivered.
Automations v1 retries individual actions. Retrying an entire failed or partially failed run is separately configurable and is off by default. A whole-run retry starts planning again against current files and destinations, so it can see different input from the original attempt.
Automations v2 retries instead resume from the first failed or partially failed node using the original revision and completed nodes' outputs. A partially failed node receives its inputs again. These are v2 early-beta semantics, not a description of v1, and v2 is not recommended for business-critical production workflows.
Do not infer that a receiving application processes a file exactly once from any of these retry mechanisms. Agree with its owner on duplicate detection and acknowledgment, especially when a connection fails after the destination may already have accepted the file.
Recover from the Known State
Before restarting work, establish which files arrived, which outputs exist, and which downstream actions have already happened. Correct the cause, such as expired credentials or an invalid record, then decide what needs replaying.
Retain recoverable inputs and protect them from routine cleanup long enough to cover your investigation window. Test whether a replay overwrites a result, creates another copy, or causes the receiving application to import the same business transaction twice. A retry cannot undo an email already sent or a file already consumed.
Document the operator's next step for partial delivery and uncertain delivery, not only total failure. Production Validation & Change Control includes those cases in the first-flow test and the handoff to operations.