Activity, Delivery & Recovery
A file workflow needs evidence of what happened and a response when the expected result is missing. Files.com provides activity records, delivery checks, and event routing for those purposes. Recovery adds another question: which files or configuration can be recovered after a mistake or failure?
For a supplier-invoice flow, receiving a file, transferring it to accounting, and importing it into the accounting application are separate results. A record of the first result does not establish the other two.
Evidence At Each Stage
Logs & Reports separates records by the work they describe. File history shows file actions; protocol logs explain connections and requests; Automation and Sync logs show execution outcomes. Configuration-change records help explain why behavior or access changed.
| Question | Evidence To Inspect |
|---|---|
| Did the supplier submit the file? | Relevant file history, protocol, Inbox, or sharing records. |
| Did the configured transfer run and deliver it? | The Automation or Sync run and its file-level results, plus applicable outbound-connection records. |
| Did the expected delivery arrive within its window? | The Expectation evaluation and any resulting incident. |
| Did the accounting application import it? | The receiving application's acknowledgment or processing record. |
The meaning of completion depends on the stage. With Buffered Uploads, Files.com finishes receiving an upload before onward delivery to the Remote Server. An upload notification can therefore arrive before the remote file is available. Investigate the onward delivery when that is the result the next process needs.
Records have their own retention periods. File-retention settings do not extend log retention. Where your investigation or audit requirements exceed the available period, plan the appropriate export or SIEM integration before the records expire.
Missing Deliveries And Alerts
An execution log can explain a failed run. A delivery can also be missing because nothing ran or the supplier sent nothing. Expectations evaluate the files in a defined scope and delivery window against criteria such as count, size, naming, and content. A scheduled evaluation can detect an absent delivery without relying on a transfer failure.
Notifications report file and folder activity to people or systems. Event Channels route operational outcomes, including Automation and Sync results and Expectation evaluations or incidents. Their delivery records establish whether an alert destination accepted a message; the receiving team's response remains a separate operational responsibility.
The distinction is useful in practice. Finance might want an email digest when invoices arrive, while operations needs an alert when the daily supplier delivery is missing or an onward transfer fails. Those audiences need different signals from the same flow. Email troubleshooting follows a missing notification through its delivery path.
Retention And Recovery
Retention determines which content remains available after changes or deletion. Restore recovers eligible resources within the supported retention window. Files deleted on a Remote Server depend on that provider's recovery capabilities; Files.com does not retain their contents as native-storage backups.
An independent backup provides a separate recovery location and policy. A copy refreshed by Sync can be part of that arrangement, but recovering an earlier version requires retaining it at the destination. A successful copy of today's invoice does not prove that yesterday's version remains recoverable. Physical Backup Exports covers an offline copy on storage you control.
Recovery also includes stopping the cause of the problem. Restoring a deleted file into a folder still subject to an unwanted deletion process can repeat the loss. Replaying a transfer can send a file the recipient already processed. Delivery Verification & Failure Recovery applies these distinctions to investigating a live workflow and choosing a safe next action.