Ownership & Security

Automation ownership determines which permissions are used when an automation runs. If the automation owner does not have access to all paths defined in the automation, the automation fails at runtime due to insufficient permissions.

To see the automation owner, add the Created By column in the Automations table. If this value is blank, the automation is owned at the site level by Site Administrators. If a username appears, the automation is owned by a specific Folder Admin user on the site.

How Ownership Is Assigned and Transferred

Ownership is assigned when an automation is created.

When a Site Administrator creates an automation, the automation is owned at the site level.

When a Folder Admin creates an automation, the automation is owned by that Folder Admin user.

After creation, ownership depends on the role of the user who last edits the automation. All edits count, including updating triggers, renaming the automation, enabling or disabling it, and updating the description.

When a Folder Admin edits an automation, ownership transfers to that Folder Admin user, even when the automation previously had site-level ownership.

When a Site Administrator edits an automation, ownership transfers to site-level ownership.

After ownership is assigned or transferred, the automation runs using the permissions associated with the current owner.

Runtime Permissions

Automations perform all file operations using the permissions associated with the current owner, not the user who initiates the run or the user who originally created the automation.

If the current owner lacks access to any source or destination path referenced by the automation, the automation fails at runtime.

For example, when a Folder Admin owns a copy files automation and has admin access to the source folder but insufficient access to the destination folder, the automation fails because the owner lacks the required permissions.

Role or Permission Changes

Changes to the automation owner’s role or folder access directly affect automation execution.

If a Folder Admin owns an automation and later loses admin access to one or more referenced paths, the automation fails at runtime due to insufficient permissions. This failure occurs when the Folder Admin loses folder admin access, has folder permissions changed, has their role downgraded, or is removed from the site.

Owner User Disabled or Deleted

If a Folder Admin who owns automations is disabled, those automations cannot run using that user’s permissions. Site Administrators can still initiate runs, but ownership does not change automatically.

When deleting a Folder Admin user who owns automations, the system prompts to reassign those automations to another user, including a Site Administrator. Reassigning ownership transfers the automation to site-level ownership. If ownership is not reassigned, affected automations stop running.

Automations owned at the site level continue to run even when individual Site Administrator user accounts are disabled or deleted.

Child Sites and Remote Servers

When an automation references folders on child sites or remote servers, the automation owner must have access to those resources.

If the owner loses access to a child site or remote server, the automation fails at runtime.

Running Automations and Viewing Logs

Automations always run using the permissions associated with the current owner. Ownership is assigned at creation and can change when the automation is edited. Ownership determines whether an automation executes successfully.

Both Site Administrators and Folder Admins can initiate automation runs when they have access to the automation.

Site Administrators can initiate runs and view execution logs for automations across the site, regardless of ownership.

When a Folder Admin initiates a run for an automation owned by that Folder Admin user, the automation runs using that user’s permissions and displays execution logs.

When a Folder Admin initiates a run for an automation owned at the site level, the automation runs using site-level permissions. Execution logs are not visible to the Folder Admin for that run.

Execution success or failure depends on the automation owner’s access to all referenced paths, not on the user who initiates the run.

Ownership Changes and Permission Related Failures

Automations fail when the current owner lacks permission to all source and destination paths, even when the automation configuration remains unchanged.

Lost Access After Role or Permission Changes

If a Folder Admin edits an automation and later loses access to one or more referenced paths, the automation fails at runtime. This failure can surface as the error Automation is owned by non admin user. This failure is caused by the Automation running with the permissions of the recent editor.

Automations owned at the site level continue to run even when a Site Administrator who created or edited them later loses their Site Administrator role or is removed.

Ownership Transfer with Insufficient Permissions

When a Site Administrator creates an automation that references paths a Folder Admin cannot access, and a Folder Admin later edits that automation, ownership transfers to the Folder Admin user.

When the Folder Admin runs the automation, the automation fails because the owner lacks permission to read from or write to all referenced paths, even though the Folder Admin can see and initiate the automation.

Resolving Ownership Related Failures

A Site Administrator can resolve ownership related failures by restoring missing permissions for the current owner, cloning the automation and deleting the failing automation, or opening the automation and saving a minor change to transfer ownership back to site-level ownership.

When deleting a Folder Admin who owns automations, the system prompts for reassignment to another user, including a Site Administrator.

Security and Operational Considerations

Automation ownership determines which permissions are used when an automation runs. Automations owned at the site level run using site-level permissions. Automations owned by a Folder Admin run using that user’s permissions.

Ownership is set at creation and can change when an automation is edited. When a Folder Admin edits an automation, ownership transfers to that user and the automation immediately runs with the Folder Admin’s permissions.

This ownership change introduces security and operational risk. Automations can silently fail at runtime when the owner lacks access to required paths, even though the automation configuration has not changed. Ownership changes can also restrict execution log visibility. Automations owned by Folder Admin users can stop working when the owner’s role or permissions change.

Administrators must account for ownership impact when creating or editing automations, especially when Folder Admins are involved.

Best Practices

Keep ownership at the site level for critical or site-wide automations.

Limit edits by Folder Admins on automations that reference paths outside their permissions. Any edit by a Folder Admin transfers ownership and can cause runtime failures.

Confirm ownership impact before allowing Folder Admins to edit automations.

Ensure automations use appropriate ownership before execution when Folder Admins require log visibility or reliable execution.