File Arrival & Data Readiness

When Files.com delivers partner files to an order importer, your workflow needs to account for all the input that application requires. An importer that needs both an order file and a line-item file cannot begin just because the first upload has finished. File arrival, readiness for processing, and the application's acceptance of the data are separate milestones in the exchange.

Even a single file can appear before it is ready. Some transfer clients create the destination while they are still writing its contents, and an interrupted transfer may leave a partial file to resume later. Seeing a filename in a directory listing therefore does not always mean its upload has finished.

Your Files.com workflow needs to follow the readiness event agreed by the producer and receiver. It might be a completed upload, a final filename, a release into a ready folder, or a marker for a whole batch. The signal needs to reflect both the producer's completion of the data and the way the client and storage make it visible during delivery.

Atomic Publication

An atomic operation becomes visible as one complete change. With an atomic upload, readers see the complete file once it is ready, without seeing intermediate bytes as they arrive. If an existing file is replaced atomically, they can continue reading the previous complete version until the replacement is ready.

A sender can still upload a complete CSV that omits expected orders or contains invalid values. Checking the export's contents is a separate step from waiting for its upload to finish.

Files.com provides atomic uploads for its native apps and supported API-based transfers. Third-party FTP, SFTP, and WebDAV clients, as well as mounted storage, can expose files differently. The completion arrangement needs to fit the client and destination actually used by the exchange.

Temporary Names and Final Renames

One way to separate writing from processing is to upload under a temporary name, such as invoices-20261109.csv.partial, and rename it to invoices-20261109.csv after the transfer succeeds. The receiver watches only for the final naming pattern, leaving a failed or unfinished transfer outside its processing input.

Both sides need to preserve that distinction during retries and agree on what happens if the final name already exists. The destination also needs to support the required rename behavior. A temporary extension helps only when the consumer consistently excludes files with that name.

A rename within one file system can be atomic, while an operation across storage systems may require copying and deletion. Object storage also has its own operation model. Before relying on the final rename as a completion signal, confirm the actual service's behavior, including the completion handling for any Files.com backgrounded operations.

Staging and Ready Folders

A separate staging folder can keep unfinished or unvalidated files away from a consumer. The producer or processing workflow releases files into a ready folder after the required work succeeds. Folder permissions control who can release input, and the consumer's selection rules determine which files it reads.

A workflow can receive files into staging, decrypt them, verify signatures, and validate their contents before releasing output. The consumer needs to read only that released output, with its triggers and selection rules keeping earlier stages outside its input. The folders provide separation; the workflow enforces the order.

When moving between locations, verify whether the move is atomic or creates a visible copy while it proceeds. If copying is necessary, use a separate completion signal at the destination instead of assuming the move's name guarantees atomic behavior.

Done Files and Trigger Files

A done file gives the receiver a separate marker to wait for before reading the data. For example, the sender can publish invoices-20261109.csv.done after completing invoices-20261109.csv. The marker can be empty or contain information in an agreed format; its meaning comes from the exchange agreement.

The order matters: data first, marker last. The receiver matches the marker to its data and handles missing data, retirement, and archival according to the agreement. A delivery-specific identity or coordinated replacement rule prevents a stale marker from releasing a new partial file.

SFTP, FTP, and WebDAV do not assign a universal meaning to trigger files. A .done file becomes a readiness signal only when the workflow implements that agreement through the relevant selection, processing, and Automation settings in Files.com.

Manifests and Batches

A manifest lists the files belonging to a delivery and can include sizes, record counts, and checksums. It is useful when the receiving application needs several files together, such as an order file and its line-item file. Publish the manifest after the batch's data files are available, or use a separate final marker for the manifest itself.

Before releasing the batch, the receiver checks that every required file is present and meets the agreed rules. The manifest helps coordinate independent uploads rather than making them atomic, so the workflow still needs defined responses to partial batches, unexpected files, replacements, and a missing manifest.

File Integrity Checksums explains comparing exact bytes. A matching checksum confirms that the receiver has the sender's declared bytes. Use the manifest's record counts or application validation to check whether those bytes contain the expected records.

Recovery at the Handoff

Test an interrupted upload, a repeated final name, a missing marker, and a partial batch. Confirm that incomplete data stays outside the consuming process and that recovery does not release an old delivery twice.

Allow enough retention for the sender to resume or resend and for the receiver to investigate. Cleanup of stale partial files belongs to the exchange agreement, with responsibility and timing that fit the recovery window. Delivery Assurance covers the next question: what to do when delivery may have completed but its acknowledgment is uncertain.