Customizing Destination Path and Filenames (v1)

When setting up destination filenames in Automations v1, you can include pattern characters that get substituted with values related to the Automation's run. The patterns below cover destination paths, trigger context, source paths, and time values. For v2, see node destinations and templates in Automations v2.

Destination Path Related

For Copy or Move file Automations, the destination path determines where files are copied, moved, or created. The path can include formatting parameters that dynamically determine the destination at runtime.

Destination Type

Destination Type decides where the Automation delivers each file. Copy to a specific folder sends every matched file to one fixed path, whatever folder it came from. Copy relative to the Automation's source path resolves the destination from wherever the Automation's source is anchored, so a single Automation can cover many folders and leave each folder's output beside it.

A path entered in Relative Destination Path begins with ./ or ../. Any path that does not begin that way is absolute.

Relative paths resolve from the Automation's source path configured by the trigger, not from the folder the matched file sits in. When the trigger has no configured path, they resolve from the site root.

Take an Automation whose source path is /Partners/, matching the file /Partners/acme/incoming/report.csv.

Both types keep the source folder structure below the destination. Flatten Folders drops that structure and keeps only the filename, which turns the second row into /Partners/processed/report.csv.

Use Copy to a specific folder when one source feeds one destination. Use Copy relative to the Automation's source path when one Automation covers many parallel folders, such as a folder for each partner, and each partner's files belong under that partner rather than pooled with everyone else's. Reaching the same result with an absolute path takes either one Automation per partner or source path tokens that rebuild the folder name by hand.

Files vs. Folders

When a destination path ends with a /, it is recognized as a folder name, and the original filename is retained. When the destination path does not end with a /, the destination field serves as a replacement for the filename.

Trigger Related

These apply only if the Automation trigger is a File Action, and refer to the filename of the triggering File Action:

For example, when the triggering file is at path/to/file.txt, the Automation destination path/to/dest/incoming-%tf resolves to path/to/dest/incoming-file.txt.

When the Automation trigger is an Inbound Webhook, any GET or POST parameters sent to that Webhook can be used by name. Parameters are limited to 190 characters each and 550 characters in total.

The pattern %u-[GET or POST Param name] is replaced by the value sent in that GET or POST parameter to the Inbound Webhook. For example, when the Inbound Webhook receives a parameter named username, the replacement pattern %u-username resolves to that value.

Source Path Related

These tokens apply based on the source path of the Automation. Source paths can include wildcard characters, and these tokens convert those wildcards in the source into meaningful values in the destination.

Two token families are available. %p tokens count folders from the matched file upward. %P tokens count folders from the root downward. Both work in destination folder paths and destination filenames, and you can mix them in the same destination.

For example, when the source file is partner/app/team/inbound/file.txt, the destination archive/%P1/%P3/%P4/ resolves to archive/partner/team/inbound/.

Here is how that works. Each folder in the source path can be referenced from either direction:

Build a destination by replacing folder names with the tokens you want. Using the same source file, the bottom-up destination archive/%p4/%p2/%p1/ resolves to the same folder, archive/partner/team/inbound/.

You can also mix token families in the same destination. For example, archive/%P1/%p1/ resolves to archive/partner/inbound/, anchoring the top-level folder while pulling the file's parent folder.

When To Use Each

Use %P when the folder you care about sits near the root and never moves, like a partner name, a department name, or a region.

Use %p when the folder you care about sits right above the file, like a date folder or a batch folder.

Mix both when you need to anchor to the root on one end and the deepest match on the other. For example, archive/%P1/%p1/ pulls the top-level folder and the file's parent folder into the same destination.

Time Related

These are always available and use the time associated with the run time of the automation. You can optionally choose the time zone used for calculating the date/time tokens in destination file or folder names. These values are similar to the values used by the strftime function in most standard code libraries.

Destination Path Replacement

For Copy or Move file Automations, destination replacement lets you rename files or reorganize their destination folders with one text rule. The Text to find in file name and Replace with settings apply to the entire resolved destination path, including fixed destination text and any source folders, filenames, or token values it contains. Every occurrence is replaced.

For example, replacing Reviewed with Final changes Reviewed/Invoice-Reviewed.pdf to Final/Invoice-Final.pdf. Matching is literal and case-sensitive; the search does not use wildcards or regular expressions.

Replacement runs after tokens and the folder or file rule have been applied. The replacement fields do not expand tokens themselves. Both fields must contain text: an empty or whitespace-only value in either field leaves the path unchanged, so an empty Replace with does not delete matching text.

Files.com resolves the result as a path again. A backslash (\) is treated as /, repeated separators collapse, and a .. segment moves to the parent folder.

Matching can span folder separators. Inserting a separator can create a folder level; removing one can join path segments.

For example, replacing acme/ with acme- changes incoming/acme/report.csv to incoming/acme-report.csv. Replacing draft- with / in incoming/draft-report.csv produces incoming//report.csv, which resolves to incoming/report.csv.

A replacement can move the destination outside the folder you configured. Replacing reports with ../archive in incoming/reports/report.csv writes to archive/report.csv. Review the final paths for the source names your workflow accepts. Files.com checks the final path after replacement against the Automation owner's permissions and its Workspace boundary, and blocks writes into Quarantine.

Overwriting Existing Files

For Copy or Move file Automations, the settings under Overwrite the Existing Files with New Ones control what happens when a file with the same name is already at the destination. Overwriting is off by default, which matches how a plain move or copy leaves an existing destination file alone.

This default helps prevent repeated transfers: an Automation with a time-based trigger and a wildcard source path can match the same files on successive runs. Enable overwriting when you intend those runs to replace destination files.

When overwriting is on, a Move Automation replaces every file whose name matches. A Copy Automation replaces a file when the sizes differ and leaves it alone when they match. Matching sizes do not establish that the contents are identical. Turning on If both their names and sizes match replaces those same-size files too, at the cost of data transfer on every run.

Files.com deletes the existing destination file before copying or moving its replacement. This gives overwrites consistent behavior across native storage and Remote Servers, including servers that cannot replace a file in place. The same sequence applies even when a particular destination supports in-place replacement.

If the replacement fails after the deletion, the previous file must be recovered using the destination's recovery options. On native storage, Restore Deleted Files and Folders can recover it during your site's retention period.

The Automation's own run log reports the whole overwrite as a single successful copy or move, so the delete only becomes visible in the logs that record activity at the destination. For a Remote Server that means the Outbound Connections log, which records the delete and the upload as separate entries. The delete also appears in File Actions History as its own event, so it can trigger any Automation or webhook set to fire on deletions at that path.

When Archive Removed Files applies, it preserves the previous destination file in the archive before the copy or move writes its replacement. A Files.com Remote Server can apply the other Site's archive rule; the mounting Site's archive rule does not apply within a mount.

When the destination is on a Remote Server, Files.com sends that delete to the remote as a real delete on that system. The remote applies its own permissions to it, so the account Files.com uses there needs permission to delete files in the destination folder as well as write to it. Without that permission the run fails on the delete and never writes the replacement.

For other Remote Servers, Files.com cannot restore the deleted remote file, so recovery depends on whether that system keeps versions of its own.

Files.com also checks your own folder permissions, separately from the remote credential. Replacing an existing destination file requires Full permission under the file replacement rule, whether the replacement is uploaded, copied, or moved. An Automation draws its permissions from its owner, not from whoever triggered the run.

Flatten Folders

For Copy or Move file Automations, you can specify whether to flatten the folder structure at the destination. When this option is enabled, the source folder structure is flattened at the destination, and all files from the source folder hierarchy are copied into the first level of the destination folder.

This is useful when copying or moving a large folder hierarchy to a single destination folder for backup or archival purposes. You can customize destination file names or specify which files can be overwritten in the destination folder for your workflow.