Destinations and Templates (v2)

In Automations v2, destination paths determine where each step writes its results. A path can be fixed or calculated with TransformScript (FTS) from the file or data entering that step.

Copy File, Move File, and Import File take one or more destinations, Create Folder takes the folders to create, and Zip takes the archive's path. Convert Document, Convert Image, Unzip, Encrypt With GPG, Decrypt With GPG, and Transform take an optional destination. For v1, see destination settings in Automations v1.

Folder or File

On Copy File and Move File, a destination path that ends with / is a folder. The incoming file retains its name and, while it remains in the trigger's source selection, its folder structure below the source-tree base.

With a trigger folder path of /Partners/ and pattern **/*.csv, /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.

Import File destinations are full filename paths, including the name to save. Create Folder destinations name folders. The other actions describe their destination and default naming rules on their own pages.

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 under a path you name.

Copy relative to the Automation's source path writes relative to the source-tree base or the current item's folder, as described below. 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 ../. Other paths start at the Automation's Workspace root, or the site root in the default Workspace.

Copy File and Move File retain the trigger's source-tree base while the current file still matches its folder path and incoming pattern. For a folder path with wildcards, the fixed part before the wildcard supplies the base, and the matched folders remain part of the retained tree.

Once an earlier node writes a file outside that selection, a later relative destination resolves from the file's current directory. A folder item uses the current folder itself. Data items and temporary files generated inside a run use the owning Workspace root, or the site root in the default Workspace.

Take an Automation whose trigger folder path is /Partners/ and pattern is **/*.csv, matching the file /Partners/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 a specific folder for a shared delivery or archive location, and a relative destination when the output belongs alongside the source tree or current file. File and folder expressions can calculate destinations when routing depends on a name within the current path. The current-item example shows how a copy to a new folder changes the next step's input and relative destination.

Transform, conversion, GPG, Zip, Unzip, and Send Email attachment paths resolve relative paths from the current file's directory, with the same root rule for data and temporary run files. They do not retain Copy File and Move File's source-tree geometry. Import File uses full filename paths and does not recreate an incoming file's folder tree.

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 on Copy File and Move File lets you rename files or reorganize their destination folders with one text rule. It replaces every occurrence of Text to Find in Destination Path with Replace With across the entire resolved destination path. That includes fixed text in the destination setting, source folders and filenames retained in the path, and text inserted by templates.

Matching is literal and case-sensitive; the search does not use wildcards or regular expressions.

Replacement runs after templates and the folder or file rule have been applied. The replacement fields contain literal text and do not evaluate templates. 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.

The resulting path is resolved again, just like a path entered in the destination setting. A backslash (\) is treated as /, repeated separators collapse, and a .. segment moves to the parent folder. The search can match text across folder separators, and the replacement can add or remove separators, changing the folder structure as well as individual names.

Replacing a filename prefix with / can also remove that prefix: replacing draft- in incoming/draft-report.csv with / produces incoming//report.csv, which resolves to incoming/report.csv.

For a double-brace template, the single-name check applies when each {{ }} value is inserted, before replacement. It does not apply to the replacement's output.

An accepted name can therefore become a folder structure or a parent-folder segment through the administrator's replacement rule. Review the final paths for the inputs your workflow accepts; the configured destination folder does not confine the result. Files.com checks the final path after replacement against the Automation owner's permissions and Workspace boundary, and blocks writes into Quarantine.

TransformScript Templates

A template is ordinary text containing TransformScript expressions in double braces. Each expression is evaluated against the current item and its result is inserted as text. archive/{{ attributes.name }} inserts the current file's name, and archive/{{ payload.customer }}/ names a folder from a value in the current data item.

TransformScript is the only expression language in v2. Percent placeholders such as %Y or %Ff in a destination are literal text. Calculated values are also used as text, without another interpretation of percent characters or braces.

For example, archive/{{ payload.name }}/ with the name %Y uses a folder named %Y. A filename containing {{ customer }} keeps those characters when inserted by {{ attributes.name }}.

File Names and Folders

Use the Strings functions to extract parts of the current file's path. The expressions below replace familiar v1 placeholders; the placeholders themselves have no special meaning in v2. Enclose an expression in double braces to insert one name, or triple braces when it supplies a path.

For partner/app/team/inbound/file.txt, archive/{{ pathSegment(directoryName(attributes.path), 0) }}/{{ pathSegment(directoryName(attributes.path), -1) }}/{{ fileName(attributes.path) }} writes archive/partner/inbound/file.txt. Negative indices count upward from the last folder, and zero-based positive indices count downward from the root. For a folder item, use attributes.path directly when selecting its own folder name or its parent segments.

An extensionless file has an empty extension. The expression {{ fileStem(attributes.path) + fileExtension(attributes.path) }} still supplies one complete name; {{ fileExtension(attributes.path) }} by itself fails the path's nonempty-name check for that file.

Dates and Parameters

For a dated destination, format the run's time explicitly:

archive/{{ (context.time as DateTime) as String { format: "%Y-%m-%d", timeZone: context.time_zone } }}/{{ fileName(attributes.path) }}

The percent characters in the FTS date-format argument keep their date-format meaning. The %files header of a complete TransformScript is also unchanged. These are TransformScript syntax, rather than v2 placeholder substitution. The date formatting reference explains the available formats.

Webhook query and form parameters are available separately from the JSON body. imports/{{ context.parameters.batch }}/{{ fileName(attributes.path) }} uses the request's batch parameter as one folder name; payload.batch reads a field in the current item's contents. Conditions can check for the values required by the workflow before the action uses them.

Paths Built From Data

In a path field, double braces insert one folder or file name. The expression's scalar result is converted to text; a result containing / or \, or equal to ., .., or an empty string, fails that item with a typed error. The node's Error Handling rules receive the error. Files.com does not silently remove the characters or choose a different name.

The check applies to every inserted value, even when it sits inside a larger path. In reports/{{ payload.folder }}/file.csv, a value of . or .. fails the item; the surrounding folder and filename do not make that value acceptable.

Use triple braces when the value intentionally supplies a path fragment. {{{ attributes.path }}} inserts the incoming file's full path, for example when attaching that file to an email. A fragment is inserted as written and can contain separators or parent-folder segments. The distinction makes it explicit whether the data supplies a name within the configured path or part of the path itself.

A .. segment moves to the parent folder wherever it appears, whether typed into the setting or supplied by a fragment. A path beginning with ./ or ../ uses the base described under Destination Type; it is not permanently anchored to the original trigger folder. Path expressions are evaluated against the current item before that resolution.

The single-name check applies to each double-brace value as it is inserted. A later Destination Path Replacement can change that text and the path's folder structure.

Neither the name check nor a replacement rule establishes that the source may select a particular destination. A fragment grants broader control, and a fixed prefix does not constrain where it can resolve.

Use fixed destinations or map accepted business identifiers to known paths when the source should not choose freely, and account for any replacement rule applied afterward. Check that the source is allowed to select the route before the node performs its action.

The resolved destination is still checked against the Automation owner's scope and cannot write into Quarantine. A Workspace-owned Automation cannot write outside its Workspace. A site-owned Automation can write throughout the site's folders, so a path outside the folder you intended may still be within its permissions. Ownership and Permissions explains how to choose that scope.

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. This gives overwrites consistent behavior across native storage and Remote Servers, including servers that cannot replace a file in place. If the replacement fails after deletion, recovery of the previous file depends on the destination's recovery options.

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.

For Copy File and Move File, Archive Removed Files preserves the previous destination file before its replacement is written. 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, 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. For other Remote Servers, Files.com cannot restore the deleted remote file, so recovery depends on whether that system retains versions of its own.