Automations v2 runs multi-step workflows on your Files.com site and is supported for production use. It has been available since September 2026 and is already running production workflows at many customers.

V2 has a shorter operational history than Automations v1. Most customers taking a conservative approach are remaining on v1 while v2 gains a longer operational history. Migration is not currently required; the migration guidance explains conversion and the planned transition to v2.

Access

Contact Files.com Support or your account manager to enable Automations v2 for your site. Describe the workflow you want to build so they can help you get started.

Automations v2 works through the API and the Web App on sites where v2 is enabled. Site Administrators and Workspace Administrators can configure v2 Automations. If you have that administrative access and see no v2 options, ask Support about enabling v2 for your site.

Getting Started

Begin with a test workflow whose inputs and expected result you can inspect. The Builder connects its steps so you can follow how files or data move through the process.

To try an existing v1 Automation, convert a disabled clone and preserve the original, because conversion is one-way. Review the trigger and destinations before enabling the test, then inspect the run's actual inputs and outputs.

Multi-Step Workflows

A v2 Automation starts from a trigger: file activity in a folder, a scheduled time, an incoming email, a webhook call from an external system, or a manual start by a person or an API call. The run then passes files or data through a series of connected steps, called nodes.

One Automation can receive a file, transform its contents, encrypt it, deliver it to two partners, and archive a copy, all in one run that records each node's result. You build the workflow as a graph of connected nodes, and run detail displays that same graph with each node's status.

In one workflow, a partner uploads a CSV of orders to an inbound folder. The Automation runs a TransformScript that converts the rows to the layout your bank requires, encrypts the result with the bank's GPG key, copies it to the bank's SFTP server through a Remote Server, and preserves the original.

An initial Copy File node creates a dated archive copy for the Transform to read. A malformed archive copy that fails the Transform node is moved to a quarantine folder instead, and the other files in the same run are still processed.

In another, Files.com receives an email with a ZIP attachment at the Automation's address. The Automation unzips the attachment, a Switch node evaluates the region field in each extracted file, and a Move File node moves each file to the folder for its region. A file whose region matches no rule is moved to a review folder.

In a third, every night at 2 AM the Automation selects the CSV files in each store's upload folder, moves each file into a dated processed folder, converts each moved file to XLSX in a dated converted folder, and sends the analytics team one email per converted file.

Automations are one of several Files.com features that move and process files. If you are not sure an Automation is the right fit, see Comparing Automations to Related Features.

What an Automation Is Made Of

Every Automation has one trigger, which defines when a run starts and which files or data it starts with. The files and data the nodes process are called items. Every other node is an action or a control.

You connect the nodes into a graph. The graph is a chain when each node follows the one before it, and it branches when one node's output is connected to two nodes or when an If or Switch node routes each item to one path.

Triggers

The trigger is the first node in the graph and the only node that receives no items from another node.

Actions

Actions operate on the files or data they receive and pass their results to the next node.

Controls

Controls route, filter, combine, delay, or transform items. Transform is the only control that writes a file itself, and only when you set a destination.

Building an Automation

You build an Automation in the Builder, which displays the workflow as a graph with the trigger at the top and each node beneath the node that supplies its input. You choose the trigger first, then add nodes and configure each one. The Builder computes the layout, so there are no positions to manage, and the same graph is always displayed the same way.

Each node shows which kinds of items it accepts and produces. When you add a node, the Builder shows which node types accept the item kinds the previous node produces, and it flags any node whose configuration is incomplete. Files.com validates the whole graph when you save it, and an invalid graph is not saved.

Every Automation is a JSON definition of its trigger, nodes, and connections. You can view and edit that definition in the Builder, and you can create, update, and run Automations from your own code through the Files.com API.

Items, Branches, and Error Paths

Each node receives items from the node before it and passes items to the node after it. An item is either a file, identified by its path, or data, which is a JSON object.

The trigger produces the first items. A File Action trigger supplies existing files in file mode or action data in event mode. A Webhook trigger supplies JSON data or selects files when configured with a folder path. Scheduled, Manual, and path-selecting Webhook triggers can also select each matched folder itself with the incoming pattern ..

Every node processes every item it receives, and some nodes change the number of items. Zip combines many files into one archive, Unzip extracts one archive into many files, and a Transform that returns a list converts one item into one data item per list element.

Connecting two nodes to the same output sends the same items to both, and both branches run in parallel. An If or Switch node routes each item to exactly one of its paths. A node whose inputs are all empty is Skipped rather than failed.

Every node after the trigger has an Error path. The node's Error Handling rules determine whether a failed item is routed to the Error path or is not processed further.

On the Error path, a Move File node can move the failed item to a quarantine folder. Without an Error Handling rule, a failed item is not processed further, and the other items in the run are still processed.

TransformScript in Automations

TransformScript lets node settings reference the items in the run. In a destination path such as archive/{{ attributes.name }}, the expression is replaced with each file's name at run time.

An If condition such as payload.amount > 1000 evaluates a value from the current item. A Transform node runs a complete script.

For a file item, payload is the parsed file contents and attributes contains the file's name, path, and other recorded details. For a data item, payload is the object itself. TransformScript in Automations lists every field that accepts an expression and what the expression in each field can read.

Ownership

An Automation belongs to your site or to a Workspace, never to a person. It runs with its owner's permissions, so it continues to run if the user who built it is disabled or deleted, and a Workspace-owned Automation cannot access files outside its Workspace.

Only Site Administrators and Workspace Administrators can manage v2 Automations. Workspace Administrators are limited to Automations in their Workspaces. Folder Admin permission alone does not grant visibility into a v2 Automation or its webhook URL, even when the user administers the trigger folder. This management boundary follows the Automation's site or Workspace ownership, whose permissions can extend beyond a Folder Admin's folders.

Runs and Revisions

Each run's run detail records the graph as it was when the run started, every node's status, the items each node received and produced, and a journal of events. Every saved change to an Automation's graph creates a new Revision, and a run uses the Revision it started with.

Run Logs lists an Automation's runs, and each row opens that run's detail, where you can cancel a run while it is running and rerun a finished run from any node. When a run fails or partially fails and retries are enabled, the new run resumes from the first failed or partially failed node and reuses the output of the nodes that completed.

Common Patterns

Beyond the three workflows above, customers write values extracted from files to metadata and route files by those values, and they define a delivery sequence once and run it from several Automations with Run Automation. Each of these patterns is built node by node in Example Workflows.

To migrate an existing v1 workflow, follow Migrating Automations v1 to v2, including the recommendation to convert a disabled clone and preserve the original v1 Automation.