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.

This greater flexibility is why v2 configuration and manual runs require Site Administrator or Workspace Administrator authority. Folder Admin access is insufficient. Unlike a v1 edit, a v2 edit does not transfer execution to the editor's personal permissions. The comparison with v1 explains the different ownership models.

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. An Incoming Email trigger limits accepted senders through Allowed Senders. A File Action trigger responds to recorded activity in the Automation's own site and cannot be started manually.

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. Inserted text is not evaluated again as another expression, even if it contains braces.

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.

The single-name check prevents a value from changing the path's folder structure, but it does not decide whether the source may select that name. Templates in settings such as recipients, request headers, and Agent Compute arguments do not apply this path check. Those values also need to be appropriate for the work the administrator intends to permit.

The resolved destination remains subject to the Automation owner's permissions. A destination cannot cross the owning Workspace's boundary or write 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.

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. Outbound Connections 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.