Both work in JavaScript, C# and Python. Every example below is shown in all three.
1. Route export files with a Files Transformation Script
If all you need is to send each run’s output files to a folder you compute, for example from an input parameter, you do not need to upload anything yourself. Every FTP, S3, Azure Storage and Google Drive export command has a Files Transformation script. Enable it, and before delivery it receives the files the run is about to deliver and returns where each one goes. Each file has a local path, akind (Data for exported data files, Extracted for downloaded files), the name of the export command that produced it, a remoteFolder relative to the Destination’s configured folder, and a remoteName. Change the folder or the name, or leave a file out of the returned list to skip it.
This example sends every file to <Path>/<inputfile>/results, where Path and inputfile are input parameters of the Agent:
2. Transfer from any script with destinations
When a script needs more than routing, for example to upload files it generated itself, to send the same output to a Destination that is not an export command of the Agent, to read a Sheet, or to pick up an input file from an SFTP server at the start of a run, use the destinations object on the script context. It is available in Script commands, in Export Scripts and in Files Transformation scripts.
File Destinations (FTP, FTPS, SFTP, S3, Azure Storage, Google Drive, Snowflake) answer
list, download and upload. Row Destinations (Google Sheets) answer readRows and appendRows. Email Destinations cannot be used from a script.
This Export Script uploads the run’s data files to the Destination named Client SFTP, under a folder computed from an input parameter. Nothing about the server or its login appears in the Agent:
Which Destination a name selects
The name is looked up among the Destinations of the Agent’s organization, so use it exactly as it appears in Control Center. If the Agent itself contains an export command with that same name, for example an SFTP export configured inline in the Agent, that command’s connection is used instead, so a script keeps working whether the connection lives in Control Center or in the Agent. A name that matches nothing fails withNo destination named '...' exists in this organization.
How folders resolve
- Every path is relative to the Destination’s configured folder.
results/2026on a Destination whose folder isexportswrites toexports/results/2026. A leading slash is ignored, and..is rejected, so a script cannot leave the Destination’s folder. - Placeholders in the Destination’s folder are expanded. If the Destination’s folder is
exports/{ConfigName}/{yyyyMMdd}, a script transfer resolves against today’s folder for this Agent.{ConfigName},{ConfigId}and .NET date formats such as{yyyyMMdd}are supported, and spaces in the expanded folder become underscores. A Destination folder without placeholders is used exactly as typed. - The folder your script passes is used as typed. Placeholders in it are not expanded. Compute the value in the script instead.
- Missing folders are created on SFTP, FTP, Azure file shares and Google Drive. On S3 the folder is a key prefix, so nothing needs creating.
- Files keep their local name. To deliver under another name, rename the local file first, or use a Files Transformation Script, which can set
remoteNamedirectly.
Limits
Testing in the Editor
Test Script runs the real transfer with your own user’s access to the organization’s Destinations, so an upload during a test really lands on the server. Two differences from a run: a Destination declared inside the Agent is not available while designing, and an Export Script sees no export files at design time, so test uploads ofgetDataFiles() with a Script command or with literal paths.