Ownership and Permissions (v2)

An Automation v2 belongs to your site or to a Workspace, never to a person, and it runs with its owner's permissions. For file operations in Files.com, an Automation owned by the site can process any folder on the site, and an Automation owned by a Workspace can process only folders in that Workspace.

A user-owned v1 Automation continues when its owner is disabled, but fails if required folder permissions are removed and is disabled if its owner is deleted without reassignment. An Automation owned by the site or a Workspace is not affected by a change to any person's permissions or account.

Site and Workspace Ownership

An Automation created on the site is owned by the site. An Automation created in a Workspace is owned by that Workspace. Every Sync, AS2 Station, AS2 Partner, GPG key, On-Premise Agent, and Automation that a node references must belong to the same site or Workspace as the Automation, and Files.com checks this when you save, because the Automation can use only its owner's resources.

Editing an Automation does not change its owner, and disabling or deleting the user who created or last edited it changes nothing about how it runs.

Who Can Access an Automation

Only Site Administrators and Workspace Administrators can manage a v2 Automation. Site Administrators have access across the site; Workspace Administrators have access only within their Workspaces. These rules apply in both the Web App and the API.

Folder Admin permission alone does not grant visibility into a v2 Automation, its configuration, or its webhook URL, even when the trigger folder is one the user administers. A v2 Automation retains its site or Workspace ownership when edited, so its workflow can access resources beyond a Folder Admin's folders.

Managing it therefore requires authority over the owning site or Workspace. This differs from Automations v1, where a Folder Admin can create and edit an Automation for the folders they administer, and an edit transfers ownership to that user.

V2 is also substantially more expressive than v1: branching, transformations, and settings built from incoming data can determine which files are changed, where information is sent, and what approved Agent programs do. This flexibility is another reason configuration is restricted to Site Administrators and Workspace Administrators. Administrators need to review the whole process and the inputs it accepts with greater care than a v1 Automation's more limited set of actions.

Who Can Start a Run

Only Site Administrators and Workspace Administrators can manually start a v2 Automation, from the Automation or through the Files.com API. Site Administrators can start runs across the site; Workspace Administrators can start runs only in their Workspaces.

Folder Admin permission does not grant manual-run access because the run uses the Automation owner's permissions. An Automation with a File Action or Folder Creation trigger cannot be started manually, because its runs start from recorded activity.

Who Sees Runs

Run visibility follows the same administrative boundary. Site Administrators can view v2 runs across the site, and Workspace Administrators can view v2 runs only in their Workspaces. Folder Admin permission alone does not grant access to v2 run records or node results.

Child Sites

An Automation belongs to one site and is managed through that site. An Automation in a Parent Site can use folders in its Child Sites as sources and destinations, through the Child Site folders in the underscore folder, and the Automation and its Run Logs exist only in the Parent Site.

An Automation in a Child Site processes only that Child Site's folders. A File Action trigger starts only from file activity recorded in the Automation's own site.

Security Considerations

The Files.com folders a run can read and write are the owner's, not those of the person who started the run. Permission to edit the workflow therefore grants authority over that data, including choosing where to send it. To limit the Files.com folders an Automation can access, build it in a Workspace and give its editors Workspace Administrator access for that scope.

An Agent Compute node selects a named definition from the commands setting on your Agent host. The Agent rejects command names that are not configured. This separates permission to build an Automation from authority to approve programs on your infrastructure.

The host administrator controls the executable and argument templates, while Automation authors supply the parameter values. Approving a command authorizes the capabilities its program exposes through those inputs, including any instructions the program accepts. Review the command definition and host permissions together.

A Workspace limits the Files.com resources an Automation can reference. It does not restrict a program launched on an Agent to equivalent folders on that host. The program uses the Agent account's operating-system permissions, independently of the Agent's file-transfer root and read/write settings.

A request to the URL of a Webhook trigger starts a run for any caller that has the URL, so treat the URL as a credential.

An Incoming Email trigger matches Allowed Senders against the message's From address. The site's Inbound email authentication setting applies to every Incoming Email Automation, including Workspace-owned ones. When enabled, it authenticates the From domain using SPF, DKIM, and DMARC results before checking Allowed Senders. A message that fails authentication is rejected.

With inbound email authentication off, the From address is not authenticated, so anyone who knows the Automation's email address can supply an allowed From address. An empty Allowed Senders list accepts any sender but still applies the site's inbound email checks when enabled. Use both authentication and a sender list when the workflow should accept files only from approved senders; a Workspace's resource boundary does not replace these controls.

Permission to start a run does not make every supplied value suitable for selecting a destination or recipient. In a path field, a double-brace template value supplies one name, while triple braces explicitly allow a path fragment.

Neither form establishes that the source may select the resulting destination. Check incoming values before they control an action, and use fixed settings or mappings to approved settings when the source should not choose freely.

A Workspace limits the workflow's scope; it does not enforce business rules about which partner may select which folder inside that Workspace. The Automations v2 Security Reference explains these decisions together.