Automation Permissions

An Automation performs work with its owner's permissions. The authority to configure it, start a run, read the results, and access the files directly are separate. Review the resulting workflow's permissions, rather than assuming it will inherit the personal permissions or API-key path restriction of the person who starts it.

The ownership model differs between Automations v1 and v2. V1 can tie execution to the current Folder Admin owner; v2 belongs to a site or Workspace so the workflow can continue independently of staff changes.

Ownership Across Versions

Site and Workspace Ownership in V2

A v2 Automation created in a Workspace uses that Workspace's resources and permissions. Referenced Syncs, AS2 resources, GPG keys, Agents, and other Automations must belong to the same site or Workspace, and Files.com checks those references when saving. Use a Workspace when the workflow needs a defined administrative and resource boundary.

Site Administrators manage v2 Automations across the site. Workspace Administrators manage them within their Workspaces. Folder Admin access is insufficient because an edit would retain the owner's broader site or Workspace permissions. This is different from v1, where the editor takes ownership under their own permissions.

A Parent Site Automation can use its authorized Child Site folders, but the Automation and its run records belong to the Parent Site. A Child Site Automation does not gain access to its Parent Site. File Action triggers respond to activity recorded in the Automation's own site. V2 ownership and permissions covers these boundaries.

Triggers and Authority to Start Work

A trigger authorizes a particular way to start configured work. A v2 Webhook trigger URL can start a run for any caller who has it, so distribute and store it as a credential. Incoming Email triggers restrict accepted senders through Allowed Senders. File Action triggers start from recorded file activity and cannot be started manually.

The triggering person or system does not become the workflow's execution owner. Review what the configured workflow can read, change, and send before making a trigger available. Possession of a trigger should authorize exactly the business process you intend to expose.

The following manual-run, edit, and log rules apply specifically to v1.

Manual Runs in V1

A Folder Admin can list, view, and manually run a v1 Automation when they have admin permission on the Automation's path, the folder it operates on. Destination folders are not part of that access check. Starting a run does not change ownership: file operations use the current owner's permissions, regardless of who starts the run.

For example, a Folder Admin who administers an intake folder can run a site-owned Copy Files Automation that writes to a finance folder they do not administer. The configured copy uses site-level permissions. This does not grant the Folder Admin permission to browse the finance folder or change the workflow while retaining site-level permissions.

Edits and Ownership in V1

An Automation created or edited by a Site Administrator is owned at the site level. An Automation created or edited by a Folder Admin is owned by that user. Every edit counts, including a name or description change and enabling or disabling the Automation.

This distinction ties the configured workflow to the authority of its editor. A Folder Admin who edits a site-owned Automation takes ownership, and subsequent runs use that Folder Admin's permissions. If the owner lacks the required source or destination access, the run fails. Changing a destination therefore does not preserve the broader permissions of the previous site-owned workflow.

Permission Changes and Log Access in V1

A user-owned Automation depends on its owner remaining enabled and having the required role and folder permissions. Disabling or deleting the owner, or removing required access, prevents it from continuing under those permissions. Starting it as a Site Administrator does not automatically change its owner. A site-owned Automation continues independently of the administrator who created or last edited it.

Folder Admins can read the saved logs of completed runs for Automations they can access, including site-owned Automations. Live run details and the dedicated logging API endpoints require a Site Administrator because the logging service cannot filter those details to individual Folder Admin permissions. This limitation applies to live log access, independently of the owner whose permissions the Automation uses. Automation Logs describes where to find the saved logs.

Ownership & Security (v1) explains how to identify the current owner, transfer ownership, and resolve permission-related failures.

Remote Connections and Local Programs

A workflow using a Remote Server depends on both its Files.com permissions and the remote account's credentials. A mounted path does not change what the remote provider grants that account. Review outbound connections and credentials when approving a source or destination.

A v2 Agent Compute node can select only a command name approved in the Agent host's configuration. The host administrator defines the executable and argument templates; the Automation supplies the parameter values. The program's interpretation of those values determines which local operations the workflow can perform. A broadly configured interpreter or script can expose any operation available to the Agent account.

The host's operating-system permissions govern that program. Neither the Automation's Workspace nor the Agent's file-transfer root and read/write settings confine the program's access on the host. Review the local operation being delegated along with the Files.com permissions before making the workflow available.

An API key's path restriction does not become the Automation's path restriction. A Full Access key that can administer Automations can configure work under the Automation owner's permissions. Use Files Only when an integration should perform direct file operations without gaining authority to configure workflows.