Automatic Delivery to Another System

An application produces an export, or a staff member finishes a report, and another system needs the resulting file. The person responsible for that exchange often inherits a second job: downloading the file, connecting to the recipient's server, uploading it, and checking that it arrived. Files.com can take over that delivery when the file is ready.

The useful handoff is a designated folder. A person or application places a completed file there, and a Files.com Automation copies it to the receiving system. The producer continues to decide what to send; Files.com handles the onward transfer. This can replace a manual step or a transfer script without replacing the application that creates the data.

Deciding When a File Is Ready

Consider an application that exports a separate report for each completed batch. The receiving system imports those reports from its SFTP server. A native Files.com folder named delivery-ready can sit between the two systems: the application uploads each finished report there, and a file-created event starts its delivery.

The folder has a business meaning: everything arriving there is ready for the recipient. Keep work in progress elsewhere. A transfer trigger can recognize that a new file was created, but it cannot decide whether the report has been approved or whether the producer included the right records.

Choose the trigger to match the actual handoff. This example uses new uploads with unique filenames. Editing an existing file, renaming it, or moving it into place can require different event choices. File Action Triggers explains those events. Establish how the producer will deliver its completed files before configuring the Automation.

Copying to a Connected System

A Copy Files Automation in Automations v1 performs this single delivery action. Copying retains the input in Files.com, which gives the workflow owner a source to inspect or resend if the recipient reports a problem. The example does not remove the input after delivery; its retention can be decided separately from the transfer itself.

The destination is a Remote Server connection: Files.com's connection details and credentials for the receiving storage. It can use a supported cloud service or protocol. A destination inside a private network can be reached through the On-Premise Agent. The destination does not need to be mounted in the Files.com file tree for an Automation to write to it.

There are separate permissions for running the workflow and reaching the remote storage. The Automation's owner determines its Files.com authority. The Remote Server's credentials determine what the receiving system permits. The account uploading the report supplies the input; it does not become the Automation's owner simply by triggering a run.

Filenames Are Part of the Agreement

The receiving system may use a filename to identify a batch, select an import process, or distinguish a new delivery from an old one. Agree on that convention with its owner. In this example, each report has a new name, such as batch-001.csv, so the recipient can distinguish successive reports and the Automation does not replace an earlier delivery.

By default, Copy Files skips a destination file whose name already exists. This matters when a producer resends a report under the same name: a run can finish without replacing the recipient's copy. If corrections must replace earlier deliveries, configure the overwrite rules deliberately and agree on how the receiving application handles a replacement. Overwriting storage does not necessarily cause that application to import the file again.

Establishing the Delivery

A Site Administrator or Workspace Administrator can set up the example in the Workspace containing the workflow. Agree on a receiving folder with the other system's owner. Use a sample that will not be mistaken for a real submission, especially if arrival starts processing there.

First, create or reuse the destination connection under Remote Servers. Follow the integration's connection requirements, then use Browse to locate the receiving folder. The remote account needs permission to write there. For SFTP, confirm the server host key with the receiving system's administrator as part of setup.

Create delivery-ready in native Files.com storage, separate from other working folders. Then open Automations and choose New Automation v1, or New Automation when only that version is available.

1. Choose Copy Files and name the workflow for its purpose, such as Deliver completed batch reports.
2. Select delivery-ready as the source. Include files directly inside it; subfolders and filename filters are unnecessary for this dedicated intake folder.
3. Choose File Actions as the trigger and select File created.
4. Select the receiving folder on the Remote Server as the destination. Preserve the filenames and leave overwriting disabled for this example.
5. Review the owner and save the Automation enabled before uploading the first report.

Each event processes the file that caused it. Enabling this trigger does not deliver files that were already in the source folder. A file-action Automation also needs an actual matching event; it does not offer Run Now.

Confirming the Whole Handoff

Upload a completed sample with a new name to delivery-ready. Open the Automation's Run Logs and inspect the operation for that file, including its destination and result. Then check the receiving system independently: the file should be in the agreed folder with the expected name and contents, and the source should remain available on Files.com.

Next, have the real producing application or staff account make a delivery through its intended process. That establishes that its permissions and method of placing the file produce the event the Automation expects. An administrator's sample upload alone cannot establish that part of the handoff.

A successful copy establishes delivery to storage. If the business outcome depends on an application importing the report, confirm acceptance with that application as well. Keep the filename or batch identifier in the delivery record so the two results can be reconciled.

For unattended operation, the person responsible for the exchange needs to hear about failed runs. Event Channels route those notifications to the team's chosen destination. Give that person access to the relevant records and agree with the recipient who handles a delivered file that fails its import. This assigns responsibility at the point where Files.com's transfer ends and the recipient's processing begins.