Automations v2

Automations v2 lets a Site Administrator or Workspace Administrator build a process that reads incoming data, makes decisions, changes files, sends requests, and calls approved programs on an Agent. Its branching, transformations, and data-driven settings make it substantially more expressive than Automations v1. An administrator approving a v2 workflow must consider what the whole process can do for the inputs it accepts, including inputs different from the examples used to build it.

Only Site Administrators and Workspace Administrators can manage a v2 Automation. Workspace Administrators are limited to Automations in their Workspaces. Folder Admin permission alone does not grant visibility into an Automation's configuration, webhook URL, or run records, even when the user administers the trigger folder.

The restriction on managing an Automation reflects the workflow's broader capabilities and site or Workspace ownership. Unlike a v1 edit, a v2 edit does not transfer execution to the editor's personal permissions.

Ownership Across Versions

V1 and v2 give configuration changes, manual runs, and account offboarding different effects. Use the ownership model for the version your workflow runs.

Execution Belongs to the Site or Workspace

A v2 Automation belongs to a site or Workspace and runs with that owner's permissions. It does not inherit the folder permissions of the person who starts it, or the path restriction of an API key used to start it. A site-owned Automation can operate throughout the site's folders. A Workspace-owned Automation is limited to that Workspace's Files.com folders and resources, and its referenced Syncs, AS2 resources, GPG keys, Agents, and other Automations must belong to the same site or Workspace.

Use a Workspace when a process needs a defined administrative and resource boundary. Within that boundary, the administrator still decides which folders and resources the particular process should use. The owner's access is broader than a rule such as "this partner's invoices belong only in this partner's folder."

Parent Site Automations can also use their authorized Child Site folders. The Automation and its run records remain in the Parent Site; a Child Site Automation does not gain access to its Parent Site. Ownership and Permissions covers administration and Child Site behavior.

A Trigger Starts the Configured Process

A Webhook trigger URL can start a run for any caller who has it, so store and distribute it as a credential. A File Action trigger responds to recorded activity in the Automation's own site and cannot be started manually.

An Incoming Email trigger matches Allowed Senders against the message's From address. The site's Inbound email authentication setting applies to Inboxes and every Incoming Email Automation, including Workspace-owned ones. When enabled, it authenticates the From domain using SPF, DKIM, and DMARC results and applies virus and spam checks before evaluating the sender list. A message that fails these checks is rejected even if its From address is allowed.

With the setting off, the From address is not authenticated. Anyone who knows the Automation's email address can put an allowed address in From, so the sender list alone does not establish who submitted the message. Leaving Allowed Senders empty accepts any sender, subject to the site's inbound email checks when enabled. Use authentication and a sender restriction together when the process must accept files only from approved senders.

These controls govern how work starts. They do not establish that every submitted field is suitable for choosing a destination, recipient, request header, or program argument. An approved partner may legitimately send documents while having no reason to choose which department receives them. A workflow that uses the partner's submitted values for those decisions delegates more than a workflow with fixed destinations and recipients.

Decide Which Inputs May Direct Work

TransformScript templates substitute a calculated value into a node setting. File contents, filenames, Custom Metadata, webhook bodies, email subjects, and output from earlier nodes may all contain values supplied by another person or system. The administrator must decide which sources and values the process can rely on for each setting.

The configured template is evaluated once per item. Each expression must produce a scalar value, which is converted to text; objects and arrays are not valid template results. TransformScript is the only expression language in v2. Inserted text is not interpreted again as a template or a placeholder, even if it contains braces or percent characters. Percent text in ordinary settings is literal; FTS date-format arguments and the %files script header keep their usual syntax.

In a path field, double braces accept one folder or file name and reject separators, ., .., and empty values. This check applies to each inserted value even inside a larger path: reports/{{ payload.folder }}/file.csv fails when the value is . or ... Triple braces explicitly accept a path fragment. For example, reports/{{ payload.customer }}/ rejects ../archive, while reports/{{{ payload.subfolder }}}/ with that fragment resolves to archive/, outside reports. The fixed prefix does not confine a fragment to that folder. Destinations and Templates explains the path rules.

Triple braces permit path structure, including separators and parent-folder components. The fragment is inserted without the single-name check; the scalar and null-byte requirements and final path checks still apply. A fragment supplied by an external system, a file, or a message can direct a write anywhere the Automation owner may write. Choose this form only when the source is allowed to supply that path structure.

On Copy File and Move File, Destination Path Replacement applies the administrator's text rule to the entire resolved path after templates and the folder or file rule. It can change fixed destination text, source folders and filenames, and text inserted by a double-brace value that passed the single-name check.

The replacement's output is resolved as a path again, without repeating the single-name check. Backslashes become folder separators, repeated separators collapse, and .. moves to the parent folder. A replacement can therefore add or remove folder levels or put the result outside the configured destination folder. This is part of the administrator's routing rule, so review it together with the template and the inputs the process accepts.

Files.com checks the final path after replacement against the Automation owner's permissions and the owning Workspace's boundary, and prevents writes into Quarantine. These checks do not decide whether a particular partner should be allowed to select another folder within that Workspace. A site-owned workflow has the site's broader scope.

Accepting a value as one name does not establish that the source may select that name. Templates in settings such as recipients, request headers, and Agent Compute arguments do not apply the single-name check. Those values also need to be appropriate for the work the administrator intends to permit.

Prefer fixed settings when incoming data has no business reason to select them. When routing must vary, map recognized business identifiers to administrator-chosen destinations or recipients. Check both that an identifier is valid and that the source is allowed to select it. Accepting a customer name from a known list does not, by itself, prove that the sender represents that customer.

Use conditions to check inputs before the first node that writes, sends, or runs a program. Route missing or unexpected values away from those actions. Review every branch and later use of the original data so that a checked value cannot be replaced by an unchecked one. Removing a few characters is not a substitute for deciding which results are allowed: different submitted values may become the same folder or filename after editing.

A value produced by an earlier transformation or AI step needs the same review. Reformatting, extracting, or generating a value does not establish that it is authorized to direct later work. Check later uses of the original input as well as uses of the new result.

A Transform node's output directive controls the format of the resulting file, while its Destination Path controls where the file goes. Format-specific escaping preserves the document's structure; it does not validate a separate path, recipient, URL, or program argument. Review the fields included in transformed files, messages, and node results so the process sends only the information its recipients need.

External Systems Have Their Own Permissions

A Remote Server uses the configured remote account's credentials. An email recipient or request URL determines where data goes. Review those destinations along with Files.com folder access; a Workspace does not define what an external account may do or who may receive information sent by the workflow.

Agent Compute selects a command name approved on the Agent host. The host administrator defines the executable and argument templates, and the Automation supplies parameter values. Review what the approved program permits through those values. A general-purpose program can perform substantially more work than a command written for one bounded task.

The program runs with the Agent account's operating-system permissions. Neither the Automation's Workspace nor the Agent's file-transfer root and read/write settings confine its local access. Files.com Agent explains the permissions involved in delegating work to an Agent.

Review the Process Over Its Lifetime

Before enabling a workflow, exercise its routing with representative inputs, missing values, and values outside the accepted business rules. Confirm the resolved folders, recipients, external requests, overwrite behavior, and program parameters. Successful processing of one sample establishes only that sample's result. Review the run details for the decisions and actions the process actually took.

Repeat that review when changing a template, condition, destination, connected account, or approved Agent program. A change to one node can alter what later nodes receive and what the workflow can do.

Disabling or deleting the creator or last editor does not stop a site-owned or Workspace-owned Automation. When retiring a process or changing who may submit work, review the Automation itself, its trigger access, and the external credentials and programs it uses. Staff account changes alone do not withdraw the configured workflow's authority.