Syncs & Automations

Use a Sync when the job is to replicate files from one folder to another. Use an Automation when the job needs its own file selection and action, such as renaming incoming files, distributing them to several destinations, or moving them into an archive. Use a Remote Server Mount when people or workflows need access to the remote files themselves.

These features can work together. An Automation can operate through mounted paths or start an existing Sync.

Replicate a Folder with Sync

A Sync has one source, one destination, and one transfer direction. It preserves the folder structure for the files it transfers and supports inclusion and exclusion patterns. It can run at an automatic interval, on a schedule, or when started by an Automation.

For example, a scheduled Sync can collect completed daily reports from a partner's SFTP server into Files.com native storage. Staff then work with the collected copies even when the partner's server is unavailable. A mount would instead give them access to the files on that server, with availability dependent on the connection.

Sync compares filenames and sizes, not modification times or checksums, when deciding what needs transfer. A changed file with the same name and size can be skipped. This matters for repeatedly overwritten exports and documents whose contents change without changing their size.

Use a transfer design that accounts for that behavior, such as unique delivery filenames or an Automation with explicit replacement rules.

A one-way Sync is not a two-way editing system. Adding a second Sync in the other direction introduces decisions about competing changes, repeated transfers, and which copy should win. Establish a source of truth before designing reciprocal transfers.

Act on Files with Automations

Automations v1 supports actions including copy, move, import, delete, create folders, and run Sync. Triggers and filename patterns determine when the action runs and which files it processes. Copy and Move actions can change destination names, flatten a folder structure, or deliver to multiple destinations.

A university collecting assignments through Inboxes could use a Copy Files Automation to collect matching submissions from student subfolders into a processing folder. A distributor could copy approved files to several destinations. Neither job is simply keeping one folder replicated.

Each v1 Automation performs one action type. For dependent actions, use separate stages with a completed-file handoff or an external application that starts each step after the preceding work succeeds. Automations v2 adds connected multi-step workflows.

Coordinating Workflows

A race condition occurs when the result depends on which of two overlapping operations reaches a file first. Sharing a folder does not by itself create a conflict. Coordination is needed when one operation changes a source file, path, or destination that another still needs.

Include Automations, Syncs, users, and applications working directly on remote storage when deciding which operation can change each file.

Copy Before Removing a Shared Source

Suppose one Automation copies incoming/report.csv to an archive while another moves it to a delivery folder. If the copy finishes first, both destinations receive the file. If the move finishes first, the archive job no longer has that source.

Arrange the work so the source remains available until every required copy succeeds. The same requirement applies when a Sync deletes source files after copying them.

For distribution to several destinations, one Copy or Move Automation with multiple destinations can replace independent jobs competing for a shared source. A Move Automation processes its destinations in order, copying to the preceding destinations before moving to the final one.

Give Independent Outputs Distinct Destinations

If two jobs deliver different files as outgoing/report.csv, an existing destination can prevent the second delivery when overwriting is disabled. When overwriting is enabled, a later replacement can replace the earlier output.

Give independent outputs distinct filenames or destination folders. If replacement is intentional, start it after the preceding operation succeeds so the retained file follows your intended order.

Release Files Only After Writing Finishes

Have the producer finish writing a file before making it eligible for pickup. It can write in a working folder and move the completed file into a pickup folder, or use a temporary filename and rename it when complete.

Configure the consumer's source path, filename patterns, and trigger to match that handoff. The producer must stop changing the file after releasing it.

Access through a Remote Server Mount does not establish that the remote application has finished writing. Some WebDAV clients also expose partial data during normal uploads; use the WebDAV completion guidance for those clients.

A scheduled delay gives a producer more time but cannot establish completion if a transfer takes longer than expected or stops partway through.

Serialize Runs Within One Automation

For repeated runs of the same v1 Automation, Always Serialize Jobs makes those runs execute one at a time. It can prevent that Automation's runs from competing for the same files, but it does not order separate Automations, Syncs, or applications.

Independent workflows need their own completed-file handoff or coordination. Offsetting their scheduled start times does not establish a dependency on successful completion.

A Run Sync Automation starts its selected Syncs without waiting for them to finish. Serializing that Automation orders its runs, not the completion of the Syncs it starts. Use Sync run results or Sync events when a later step depends on a Sync's result.

Check Replacement Permissions

A Copy or Move operation that overwrites a destination deletes the existing file before writing its replacement. On a Remote Server, the configured account therefore needs permission to delete as well as write. The Automation's owner must also have the required access in Files.com.

A Sync normally replaces a remote file by uploading over it. Its permission requirements include exceptions: some SFTP servers require deleting before replacement, source cleanup needs delete permission, and FTP cleanup can delete an incomplete upload. Test against the particular server instead of assuming every Sync can work with write-only credentials.

Match the Failure Behavior to the Job

A Sync lists both sides on each run and can pick up missing or different-size files later. That helps recover from an outage while the source files remain available, but does not guarantee recovery after the producer deletes them. An Automation has its own selection, overwrite, and retry rules.

For either feature, finish writing source files before making them eligible for pickup. Retain inputs long enough to investigate failures, inspect partial results, and test repeated execution. Use a Sync dry run to inspect selection before the first transfer, then verify a small live transfer with representative files.