Troubleshooting Automations (v1)

An Automation v1 can fail for every file in a run or only some files, leaving the rest transferred successfully. The Automation logs record the errors to investigate. If automatic retries are enabled, Files.com reruns an Automation after Failure or Partial Failure; retries are off by default.

For v2, use Troubleshooting Automations v2, which covers node inputs, branches, and error paths.

Investigate the result at the file level before changing the workflow. Distinguish files that were not selected from files that were selected but could not be transferred, then compare the source, destination, and permissions involved. A problem affecting every file calls for different checks from one affecting a single name or an existing destination.

Use this guidance when diagnosing missing output, skipped work, or repeated failures. Establishing what actually happened helps you correct the cause and decide whether rerunning the work will produce the intended result.

When several jobs use the same files, investigate overlapping workflows to compare selection, writes, and completion across Automations, Syncs, users, and remote applications.

Source Selection Problems

A file can be missing from the output because it was never selected for processing. Check the source path, matching patterns, and folder size before investigating a transfer failure.

Using Wildcards Incorrectly

When wildcards appear in Automations v1 folder paths, the matching pattern has to line up with the files you want to act on.

For example, a Folder path of Partners/Invoices/ selects files directly in that folder. Partners/Invoices/* selects its immediate subfolders, while Partners/Invoices/** includes the folder and its subfolders at every depth. Compare the folder path and file-name patterns with the missing file's actual path before changing the selection.

If a v1 Automation's folder path is on a Mounted Folder or Remote Server, folder path globs such as * and ** for including subfolders are only supported with file-action triggers. Other trigger types return the error Globs are not supported on remote path.

Source Folder Size

If an Automation v1 fails with a source-folder size error or spends a long time selecting files, check the number of items in each source folder it lists. Count all files and subfolders, including items that do not match the Automation's file-name patterns. Selecting only the newest files does not avoid reading the full listing.

Compare the folder size with the source selection limits: fewer than 10,000 items per folder is recommended, and a listing that reaches 100,000 items causes the run to fail. Check the trigger as well. A file action-based trigger selects the affected file directly, so this listing limit does not explain a failure in that type of run.

Split a large source collection into smaller folders and update the Automation's source paths and patterns to match the intended files. Automatic file organization can move files into subfolders by extension, creation date, modification date, or regular expression. After reorganizing, verify that the next run selects the expected files.

If your retention requirements allow old files to be deleted, File Expiration can keep the active folder from growing indefinitely. Choose an expiration period based on those requirements, rather than deleting needed files solely to reduce the count.

Source Not Found

When an Automation v1 is configured to perform an action based on a source folder or file, and that source folder or file is not found, the automation outcome is logged as a failure.

Confirm the source path in the Automation matches the actual location of the folder or file, and verify that the owner of the Automation has the correct access permissions to it.

A missing source file can also indicate a race condition in which another process moved or deleted the file before the Automation ran.

Destination Exists

When an Automation v1 moves or copies a file and a file or folder already exists at the destination path, Files.com does not replace it. What happens to the run then depends on the Automation type.

A Move Automation records a failure against that file, with the message "The destination exists."

A Copy Automation records the file as skipped, with the message "already exists on destination", and the run itself completes successfully. A Copy Automation that appears to have worked can therefore leave the destination file untouched.

When replacing the file is what you want, turn on overwriting for the Automation.

Compare the resolved destination paths and file activity across workflows to identify which operation created the existing file. Another job writing the same path is one possible cause; an existing file alone does not prove a race condition.

If overlapping runs belong to the same Automation, Always Serialize Jobs can prevent those runs from executing at the same time. It does not coordinate separate Automations or Syncs, and it does not remove a destination left by an earlier run. Choose distinct output paths or an intentional replacement policy using the workflow coordination guidance.

Same-Size Files Are Skipped When Copying

When a Copy Files action in Automations v1 completes successfully but a source file does not appear at the destination, the cause may be that a file of the same size already exists there. In this case, Files.com skips the copy and the automation reports success but the file is not transferred.

This most often occurs when a file has been updated at the source but its size has not changed.

To transfer files regardless of whether a same-sized file already exists at the destination, enable If both their names and sizes match in the Automation's destination settings. It applies only when If their names match but sizes are different is also on. We recommend leaving this option disabled to avoid wasted data transfer.

Zero-Byte Files Are Not Delivered

A zero-byte file has a name but no contents. It can be an intentional workflow signal, such as an end-of-Sync trigger file. Azure Blob Storage supports storing and downloading empty files.

If a Copy or Move Automation v1 does not deliver an expected empty file, confirm that the file matches the Automation's source selection and is still available at the source. Check whether a file with the same name already exists at the destination. A Copy Automation can skip a same-size destination file according to its overwrite settings; two empty files have the same size.

Review the Automation logs for the affected file. For a Remote Server connection, also review the Outbound Connections log for a specific connection or transfer error. If a selected file has no recorded outcome, or an empty-file transfer fails without an explanation, contact Support with the Automation, run time, and source and destination paths so the failure can be investigated.

Automation Is Owned by Non-admin User Error

In Automations v1, the error "Automation is owned by non-admin user..." indicates that the automation is owned by a Folder Admin user who no longer has the required permissions to all source or destination paths referenced by the automation.

In v1, ownership follows the most recent editor, so a Folder Admin's revised automation uses that user's permissions even if a Site Administrator originally created it. An edit can therefore expose missing access to a source or destination without changing either path.

A Site Administrator can restore the missing permissions for the current owner or open the Automation and save a minor change to transfer ownership to site-level. Alternatively, they can clone the Automation and delete the failing one.

When deleting a Folder Admin user who owns automations, the system prompts to reassign those automations to another user, including a Site Administrator.

Remote Connection Failures

Automations v1 actions that use a Remote Server depend on that connection being available. When Files.com detects a timeout or network problem, the failure is recorded in the logs.

Timeout Errors or Network Issues

Start with the error in the Automation logs. Identify the affected Remote Server and review its Outbound Connections log. Confirm that the connection is enabled and that its address, credentials, and network access rules allow Files.com to connect. This ties the troubleshooting to the connection that failed.

If a run or expected file is missing, distinguish work that was not selected from an attempted operation that failed. Contact Support if the expected run or failure record cannot be accounted for, and include the Automation, file path, and expected run time.

Rate Limit Throttling

Some remote servers limit the number of connections that can be made to them. These limits are enforced by the remote system, not by Files.com.

When an Automation v1 moves large quantities of files to a rate-limited remote server, you'll see errors like this in the logs:

Errored while trying to Connect: 'Activity Limit Reached: The request has been throttled'

Files.com reacts to these rate limit warnings by slowing down reconnection attempts and reattempting the actions later. The remote server determines the rate limit, and Files.com has no way to know what that limit is until it's hit.

Check the remote server's throttling settings, activity logs, or connection limit settings to find the threshold.

Adjust the Automation's concurrency, file batch size, and scheduling until you find a combination that completes the work without triggering the throttle.