Scheduled Collection From Another System

A supplier publishes files to its server each night, but your organization is responsible for retrieving them. Or an internal application writes exports to storage that other teams cannot access directly. Files.com can collect those files on a recurring schedule and place a copy where your people or applications can use it.

This arrangement leaves the producing system in place. Its owner prepares the files; Files.com connects to retrieve them. A server-side Sync performs the collection, so it does not depend on a staff member's computer, Desktop App, or scheduled script being available.

Understanding the Feed Before Scheduling It

Suppose a supplier produces one new report per day for an internal application. The supplier owns the source folder and knows when its export is complete. Your team owns collection and needs the report in time for the application's morning processing.

Agree on three things before choosing a schedule: how a completed report is identified, how corrections are published, and when the consuming application needs the data. A pickup folder containing only finished files gives the collection a clear meaning. The supplier can finish writing elsewhere and then place the completed report there. A clock alone cannot establish that a file is ready if the export runs late.

Filenames matter because a Sync compares paths and sizes to decide what needs copying. A feed that publishes newly named files, such as report-2026-09-18.csv, fits this model. A file already present at the destination with the same path and size is skipped, even if its contents have changed. This comparison selects files for transfer; it is separate from checks performed during the transfer itself.

If the producer repeatedly replaces latest.csv, including with same-size revisions, use an Automation with explicit overwrite behavior suited to that handoff. Decide this before configuring collection, rather than discovering later that a correction did not replace the destination copy.

A Collected Copy Has a Different Role From a Mount

A Sync creates a separate copy. Once collected into native Files.com storage, the report is available there without retrieving it again from the supplier's server. That is useful when staff or an application need the delivered files after the supplier's pickup window ends.

A Remote Server Mount instead provides access to files at their existing location. It fits a requirement to browse and work with the source. Collection fits a requirement to receive files into another location. For the supplier feed, the collected folder is the internal application's input; changes to that copy are not sent back to the supplier by the one-way Sync.

Keeping the supplier's originals makes the first collection easier to confirm and preserves them for other consumers. If the agreement later calls for removing files after pickup, that is a separate decision with the supplier, not an automatic consequence of receiving a copy.

Connecting the Source and Proving the Collection

Use a Site Administrator account or a Workspace Administrator account for the Workspace containing the workflow. The source needs a Remote Server connection with credentials permitted to list and read the pickup folder. Create or reuse that connection under Remote Servers, following the service's integration requirements. Use Browse to locate a completed sample and confirm that it can be read.

Create a native-storage destination such as collected-reports. For this first collection, leave filename rewriting and file transformation settings off that folder so the source and delivered copy can be compared directly. Agree on a small source folder for the exercise, rather than beginning with the supplier's entire archive.

Under Syncs, create a one-way Sync from the remote pickup folder to collected-reports. Set it to keep source files after copying. Leave include and exclude patterns unset for this dedicated source folder, and choose External Trigger. Save it enabled. This trigger allows a manual start while you establish the transfer; no recurring schedule is active yet.

1. Use Dry run and inspect the projected operations in the Sync Runs Log. Confirm that the selected files and destination paths match the intended collection. A dry run makes no changes.
2. Select Run now. Inspect the completed run for transferred files and errors.
3. Download the collected sample from Files.com and compare it with the source. Confirm that the original remains at the supplier's location.

The dry run checks what Files.com plans to do. The completed transfer checks access and the resulting copy. Neither establishes that the internal application can use the data, so give it a representative report and confirm its import separately before relying on the feed.

Working Backward From the Business Deadline

Set the recurring schedule once the collection and receiving application work together. Edit the trigger to Custom Schedule, then choose the days, time of day, and time zone. The source's expected completion time and the consumer's deadline determine the useful collection window.

A scheduled time defines an hour-long start window. Allow for that window, the transfer, and the application's processing when deciding how early to collect. For example, a report required by an early-morning process needs to be ready and collected before that process starts; selecting its start time as the collection time leaves no room for the preceding work. Sync Triggers explains schedule and concurrency behavior.

Have the supplier publish another completed report with a new name before the next collection window. Confirm that it arrives without a manual start and that the application processes the collected copy. This establishes the scheduled path using the producer's real publication method.

A Successful Run Can Still Mean a Missing Report

A Sync can successfully find nothing new to copy. That result means the collection had no new input; it does not establish that the supplier met its obligation to publish the day's report.

For a recurring feed, use an Expectation to check for the expected delivery by its deadline, alongside reporting for failed Sync runs. Those checks answer different questions: whether collection failed and whether the required file arrived. Delivery Verification & Failure Recovery explains how to route the results and investigate the responsible stage.

The person operating this feed should know who can correct a missing source file, repair the connection, or address an import failure. Recording those responsibilities with the filename convention and delivery deadline makes the arrangement maintainable when the person who first configured it is unavailable.