Skip to main content

Destinations and Templates

Every node that writes a file takes a destination path, and the path can be fixed or built from the item at run time. Copy File and Move File take one or more destinations, Create Folder takes the folders to create, Zip takes the archive's path, and Import File takes the path of the file to save. Convert Document, Convert Image, Unzip, Encrypt With GPG, Decrypt With GPG, and Transform take an optional destination.

Folder or File

A destination path that ends with / is a folder. The incoming file retains its name and its folder structure below the trigger's folder path, so with a folder path of /Partners/ the destination /processed/ receives /Partners/acme/report.csv as /processed/acme/report.csv. A path that does not end with / names the file itself, and its last segment replaces the incoming file's name.

Parent folders that do not exist are created.

Destination Type

Each destination on a Copy File or Move File node has a Destination Type. Copy to a specific folder writes every file under one path you name, from any folder. Copy relative to the Automation's source path resolves the destination from the Automation's source path, which is the trigger's folder path, so one Automation covers many parallel folders and writes each folder's output next to that folder. The Move File node offers the same two types under the names Move to a specific folder and Move relative to the Automation's source path.

A relative path begins with ./ or ../. Any other path is absolute.

Relative paths resolve from the folder path configured on the trigger, not from the folder the matched file is in. When the trigger has no folder path, they resolve from the site root. In an Automation with more than one node, they still resolve from the trigger's folder path, not from the previous node's output folder.

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

Destination TypePathWhere the file is written
Copy to a specific folder/processed//processed/acme/incoming/report.csv
Copy relative to the Automation's source path./processed//Partners/processed/acme/incoming/report.csv
Copy relative to the Automation's source path../archive//archive/acme/incoming/report.csv

Both types retain the source folder structure below the destination. Flatten Folders retains only the filename, so ./processed/ writes the file as /Partners/processed/report.csv.

Use Copy to a specific folder when every matched file belongs in one destination folder. Use Copy relative to the Automation's source path when one Automation covers many parallel folders, for example a folder for each partner, and each partner's files belong under that partner rather than mixed with every other partner's. Writing each partner's files under that partner with an absolute path takes either one Automation per partner or folder tokens that rebuild the folder name.

Copy File and Move File accept more than one destination. A Move File node with several destinations writes the file to every destination before the original is removed.

Flatten Folders

Flatten Folders removes the source folder structure and writes every file directly in the destination folder. It is the setting for collecting a folder tree into one folder.

Destination Path Replacement

Destination Path Replacement replaces exact text in the resolved destination path after templates, tokens, and the folder or file rule have been applied, so it can change a folder name or a file name. Text to Find in Destination Path names the text and Replace With gives its replacement. A destination that resolves to Invoice-Reviewed.pdf with Reviewed replaced by Final is written as Invoice-Final.pdf. Matching is case-sensitive, and the two fields take plain text only, because the replacement runs after tokens and templates are resolved and matches the resolved text exactly.

Tokens

A destination path can contain tokens that Files.com replaces when the file is written.

Folder tokens name folders from the incoming file's path. %p tokens count from the file upward, and %P tokens count from the root downward.

TokenDescription
%p1, %p2, %p3, ...Folder name in the source path, counted upward from the matched file. %p1 is the file's parent folder.
%P1, %P2, %P3, ...Folder name in the source path, counted downward from the root. %P1 is the top-level folder.

For the file partner/app/team/inbound/file.txt, the destination archive/%P1/%P3/%P4/ resolves to archive/partner/team/inbound/, and so does archive/%p4/%p2/%p1/. The %p and %P tokens can be combined in one path, so archive/%P1/%p1/ resolves to archive/partner/inbound/. Use %P for a folder near the root that never moves, like a partner or department name, and %p for a folder right above the file, like a date or batch folder.

File name tokens insert the incoming file's own name, so a destination can build the file's new name from its original name.

TokenDescription
%FfThe name of the source file, with extension
%FbThe name of the source file, without extension
%FeThe extension of the source file
%FlThe name of the source file, with extension, converted to lowercase
%FnThe name of the source file, without non-alphanumeric characters, with extension
%FpThe name of the source file, with extension, spaces removed, lowercase, non-ASCII normalized

Trigger tokens refer to the file that started a File Action run and apply only with that trigger.

TokenDescription
%tpEntire path of the triggering file
%tfFilename of the triggering file, without folder name
%tdFolder name of the triggering file, without file name
%tbFilename of the triggering file, without folder name and extension
%teExtension of the triggering file

Date and time tokens take the time the run started, in the trigger's Path Time Zone, and follow the strftime names.

TokenDescription
%aAbbreviated weekday name, for example Mon
%AFull weekday name, for example Monday
%bAbbreviated month name, for example Jan
%BFull month name, for example January
%CCentury number, the year divided by 100, 00 to 99
%dDay of the month, 01 to 31
%eDay of the month, 1 to 31
%HHour on a 24-hour clock, 00 to 23
%IHour on a 12-hour clock, 01 to 12
%jDay of the year, 001 to 366
%mMonth, 01 to 12
%MMinute, 00 to 59
%pam or pm
%rTime in am and pm notation
%RTime in 24-hour notation
%SSecond, 00 to 59
%TTime, equal to %H:%M:%S
%uWeekday as a number, 1 to 7, with Monday as 1
%UWeek number of the year, counting from the first Sunday as the first day of week 1
%VISO 8601 week number of the year, 01 to 53, where week 1 is the first week with at least 4 days in the year and Monday starts the week
%WWeek number of the year, counting from the first Monday as the first day of week 1
%wWeekday as a number, 0 to 6, with Sunday as 0
%yTwo-digit year, 00 to 99
%YFour-digit year
%ZTime zone name or abbreviation
%%A literal %

The same date and time tokens can be used in the trigger's folder path and file pattern.

TransformScript Templates

A destination path can also contain TransformScript expressions in double braces, evaluated for each item. archive/{{ attributes.name }} inserts each file's name, and archive/{{ payload.customer }}/ builds a folder from a value inside a data item. Tokens and templates can be combined in one path, so archive/%Y/%m/{{ attributes.name }} writes each item under the current year and month.

Overwriting Existing Files

Overwriting is off by default on Copy File, Move File, Convert Document, Convert Image, Zip, Unzip, Encrypt With GPG, and Decrypt With GPG, because the common pattern of a scheduled trigger with a wildcard folder path would otherwise copy the same unchanged files on every run, which would use data transfer and add log entries without changing any file. With it off, a file that already exists at the destination is not replaced. On a Copy File node the copy is skipped and run detail records it as skipped. On Convert Document, Convert Image, Zip, Unzip, Encrypt With GPG, and Decrypt With GPG the item fails with the error processing-failure/destination-exists, which the node's Error Handling rules can route.

On a Move File node, Overwrite the Existing Files with New Ones replaces every file whose name matches. On a Copy File node, If their names match but sizes are different replaces a file when the names match and the sizes differ, which skips files whose size at the destination is the same, and If both their names and sizes match replaces same-size files too, at the cost of transferring every file on every run. On the other nodes, a single overwrite setting replaces any existing file.

Files.com deletes the file already at the destination, then writes the new file in its place, the same way a plain move or copy replaces a file. The delete is recorded in File Actions / History as its own action, so it can start any Automation or webhook set to run on deletions at that path, and for a file stored on Files.com it is a soft delete that Restore can recover during the site's retention window. Archive Removed Files does not capture a file replaced this way, because that setting archives files replaced by an upload or a Sync, and an Automation deletes the existing file instead.

When the destination is on a Remote Server, Files.com sends that delete to the remote as a real delete, and the Outbound Connections log records the delete and the upload as separate entries. The account Files.com uses on the remote needs permission to delete files in the destination folder as well as to write there. Without that permission, the item fails on the delete and the replacement is never written. Files.com cannot restore a file deleted on a remote, so recovery depends on whether that system retains versions of its own.