Tray

Tray workflows can collect files from Files.com, use their contents in application steps, and publish resulting files back through Tray's FTP Client connector configured for SFTP. Files.com gives outside senders a controlled exchange location while Tray owns the workflow's application calls and decisions.

For example, a vendor can submit an order file through its Files.com account. Tray downloads the prepared file, creates the receiving application's records, and publishes a response that the vendor can retrieve. The vendor needs access to its submission and response folders; the workflow uses its own credential for the file operations.

FTP Client Authentication

Create a dedicated Files.com machine account and enable SFTP. Assign listing and download access for collection, upload access for results, and any additional permissions the workflow needs to move or remove files.

In Tray's FTP Client connector, create an authentication with SFTP as the protocol, your site's hostname or custom domain as the host, port 22, and that account's username. For key authentication, place the private SSH key in Tray and register its public key on the Files.com user. Choose the authentication's sharing scope so the people maintaining the workflow can use it.

Use paths visible to the account. A Files.com SFTP client root can make a dedicated integration folder appear as /, so the workflow's paths start there. The SFTP connection settings cover account authentication, hostnames, and network access. Files.com supplies the endpoint; there is no separate FTP server to install for this connection.

Files Between Workflow Steps

Choose whether a schedule or a file event starts processing. A scheduled workflow can list the pickup directory and download selected files. A Files.com Webhook can instead notify an incoming Tray webhook trigger about file activity. The notification describes the event; the workflow still retrieves the file it needs.

Keep the pickup selection limited to completed, prepared input. If Files.com performs decryption or transformation, publish the result to the pickup folder after the required preparation succeeds. Keep retained originals and previous outputs outside that selection.

Pass the downloaded file to the connector that interprets its contents. For CSV processing, Tray's CSV workflow guidance explains the relationship between downloading a file and reading its rows. A directory listing or filename identifies the input; it does not supply the contents to the business application.

For output built from application data, File Helpers can create a file from prepared content. Pass that file to the FTP Client upload operation and set the destination path and filename the recipient expects. Choose the file's actual format before naming it: changing an extension does not convert its contents.

Tray file references have a limited lifetime. Publish output that needs durable retention to Files.com rather than using a workflow's temporary download URL as the recipient's long-term file location. Tray's technical limits also distinguish file handling from the size of data passed directly between steps.

Completed Application Work

Place input cleanup after the application result that permits the exchange to advance. Record which delivery the workflow processed so another event or a repeated scheduled run does not create the same business action again.

Test the download, application action, and output upload together. Use Tray's workflow logs and Files.com SFTP Logs to identify the failed stage before rerunning it. An upload error can follow a successful application action; repeating the whole workflow without checking that result can submit the same records twice.