Automations v1

A v1 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.

V1 can tie execution to the current Folder Admin owner, and an edit can change that ownership. Automations v2 instead belongs to a site or Workspace and uses different administration and execution rules.

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

Disabling a v1 Automation's Folder Admin owner ends that person's access but leaves the Automation running with the same owner's folder permissions, regardless of its trigger or who starts the run. Removing required folder permissions makes runs fail; deleting the owner without reassignment disables the Automation. 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.

During offboarding, disable the Automation to stop the workflow or transfer ownership to keep it running under another owner's permissions.

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 Configuration Credentials

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.

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.