Administrative permission levels define what management actions a user account can perform within a Files.com site. They let Site Administrators delegate responsibilities, limit access to sensitive controls, and separate duties across teams without granting full administrative access to every user.

Administrative permissions grant clearly scoped capabilities. Some provide full control over the site. Others allow limited administration of users, folders, billing, or visibility into system configuration and logs.

Administration and Data Access

Anyone who controls where files are sent must be trusted with the files those workflows can access. Data access includes directing Files.com to copy, send, change, or delete files, as well as opening or downloading them. For example, an administrator who can change a Sync's destination to a remote server they control can receive its files there without downloading them through the Web App. Restricting Web App downloads does not remove the authority to send files elsewhere.

Choose administrative permissions according to the data and resources the person is trusted to manage. For someone maintaining integrations for one team or business process, Workspace administration limits that authority to the assigned Workspaces. It still includes full access to the files within those Workspaces. The administrator's permissions and the workflow's permission rules determine the scope of that access; permission to configure a workflow does not give every administrator access to all data on the site.

Review delegated administration through both configuration changes and the resulting activity. The Settings Changes log records who changed settings and what changed. Sync Runs and Automation logs show execution results, while Outbound Connections records individual actions on remote systems. These records help you review how authority was used; they do not limit the administrative authority granted.

Site Administrator

Site Administrators have the most powerful level of access to your site. A Site Administrator can manage everything within your Files.com site, with no restrictions on the types of records they can change. For this reason, limit Site Administrator status to users who require that level of access.

When a new site is created, the first user is a Site Administrator. That first user account may be modified by any other Site Administrator.

Site Administrators and Child Sites

Every Site Administrator on a Parent Site has full Site Administrator authority on all its Child Sites, including full access to files and management of users, settings, and integrations. This is an inherent part of Parent Site Administrator access and cannot be disabled or restricted on a Child Site. Keep Parent Site Administrators to the minimum necessary and protect those accounts and their credentials.

Users of a Parent Site can be made Site Administrators for a Child Site. This grants the same access as creating their account within the Child Site and configuring them as a Site Administrator there, but requires less configuration. You provision the user once in the Parent Site and manage their access to relevant Child Site content, instead of re-creating separate user accounts in each Child Site for the same person.

Parent Site users can be members of a Group that is granted Site Administrator access to a Child Site, making it even easier to delegate administration for your Child Sites.

Users with Site Administrator access for a Child Site have full control over every file and folder within the Child Site. They can configure any of the settings for the Child Site that are not blocked by a Child Site Management Policy. Parent Site Administrators can also change or remove those policies from the Parent Site, so policy locks do not limit their ultimate authority.

Read-only Site Administrator

A Read-only Site Administrator sees exactly what a Site Administrator can see, nothing less. This access is for people who need to troubleshoot, audit, or review the site without changing its configuration. References throughout this documentation to what Site Administrators can view apply equally to Read-only Site Administrators; the restriction is on making changes, not visibility.

Granting this visibility requires a level of trust close to that required for a Site Administrator. The restriction on changing configuration does not reduce the confidentiality of the information the person can read. Limit this access to people who need that broad visibility, and apply the same care to account protection and access reviews as for Site Administrators.

Users can be configured as a Read-only administrator in the user's settings. Read-only Site Administrators explains the trust required and how this access combines with separately granted permissions to make changes.

Accounts with this access must use the Site Root file system layout; other layouts cannot be assigned.

Permissions granted separately still authorize their usual actions. For example, Share permission allows the user to create Share Links, and Folder Admin permission allows them to manage the supported settings of that folder. Granting this access does not remove those permissions.

To grant this access through SCIM provisioning, use Provision users in these groups to be read-only site admins in your SSO provider's configuration. Enter comma-separated IdP group names or wildcards, such as Support Admins,Audit Team. Users in those groups receive Read-only Site Administrator access.

Site Administrators can configure a Read-only Site Administrator to receive alert emails about problems with their site. The available alert categories are Site warnings, SSO/SCIM/LDAP configuration/sync failures, User security events, Pending work failures, SIEM failures, Sync failures, Automation failures, and Expectation failures and misses. Each category is a separate preference that can be enabled independently.

Site Administrators cannot be granted the Read-only Site Administrator privilege, because Site Administrators have full access to everything within your site.

Read-only Site Administrators and Child Sites

Users of a parent site can be made Read-only Site Administrators for a child site. This grants the same access as creating their account within the child site and configuring them as a Read-only Site Administrator there. This approach requires less configuration than creating separate user accounts for each child site, and it lets your users log in at a central parent site to access any of their child sites.

Parent site users can be members of a group that is granted Read-only Site Administrator access to a child site, making it even easier to delegate that access for your child sites.

Within that Child Site, the user sees exactly what its Site Administrators can see, without permission to change its configuration. The grant does not provide access to the Parent Site or other Child Sites.

Workspace Administrator

Workspace Administrators have full administrative control within their assigned Workspace. They can manage all resources within their Workspace, including users, groups, partners, folders, automations, remote servers, syncs, notifications, security keys, and data governance settings. Their administrative authority is limited to their assigned Workspaces; site-wide settings remain under Site Administrator control. A user can be a Workspace Administrator for one or more Workspaces.

Site Administrators can designate a Workspace Administrator by switching to a Workspace and creating a new user with Workspace Administrator access, or by granting that access to an existing Default Workspace user for a specific Workspace. Workspace Administrators can also designate additional Workspace Administrators within their own Workspace by creating a new user with Workspace Administrator access or by promoting an existing Workspace user.

A Default Workspace user granted Workspace Administrator access can also see the Default Workspace's users and groups through Folder Admin directory visibility. This lets them find users and groups when assigning folder permissions and notifications; it does not grant authority to administer those accounts or groups. Cross-workspace access explains the grant and its limits on visibility into Default Workspace folder records.

Partner Administrator

Partner Admins are Partner Users who are designated to manage users within their own Partner. Their authority is limited to the Partner boundary and does not extend to site-level settings, internal users, Groups, or resources outside the Partner.

Site Administrators and Workspace Administrators designate Partner Admins within their respective scopes. Editing, enabling, disabling, and deleting accounts are included in Partner Admin access. The Partner Admin settings add optional capabilities for creating users, changing credentials, overriding 2FA requirements, and managing GPG keys; turning them all off does not remove the basic account-management powers of Partner Admins. Partner Admins have the same folder access as other Partner Users, cannot be added to Groups, and cannot hold administrative permissions outside the Partner.

Group Admin

Each group can have one or more members designated as Group Admins. A Group Admin manages users whose Primary Group is one of the groups they administer. This lets users join multiple groups for shared access while keeping account-management authority with one designated group.

Site Administrators decide site-wide which user-management capabilities Group Admins can use. The available actions are creating users, adding or removing existing users, editing user details, enabling or disabling accounts, deleting users, setting and resetting passwords, resetting enrolled 2FA methods, and exempting individual users from User Lifecycle Rules. Account changes apply only to eligible users whose Primary Group they administer. Membership management can add or remove eligible members of their groups regardless of the user's Primary Group.

Group Admin account-management capabilities never apply to Site Administrator or Workspace Administrator accounts, even when the administrator's Primary Group is one they administer. No Group Admin capability allows editing, enabling, disabling, or deleting those accounts, setting or resetting their passwords, resetting their 2FA, or exempting them from User Lifecycle Rules.

Site Administrators retain full control over all users and groups across the site. Workspace Administrators can manage users and groups within their workspace scope.

If a Site Administrator or Workspace Administrator is also assigned as a Group Admin, this does not provide any additional permissions beyond their existing full access.

Delegated Administration explains how to choose Group Admin and Partner Admin capabilities, including their effects on inherited access, credentials, account lifecycle, and offboarding.

Folder Admin

Folder admin is a user or group permission granted for a folder. Folder admins have full control over all the Folder Settings and Automations v1 for a folder, and unlimited access to the contents of their folder. The exception is the site's root folder, where Root Folder Settings can allow only Site Administrators to change folder settings, even if a user has Folder Admin permission on the root.

Managing Automations v2 requires Site Administrator or Workspace Administrator access. Workspace Administrators are limited to their Workspaces. Folder Admin permission alone does not grant visibility into a v2 Automation, its webhook URL, or its runs, even when the user administers the trigger folder. V2 Automations run with their owning site's or Workspace's permissions, which can extend beyond the folders a Folder Admin administers.

Folder admins can see Folder Settings configured on folders above theirs, including the site root, only when those settings are recursive and apply to a folder they administer. This lets them understand inherited rules affecting their folders. Non-recursive settings and settings whose scope does not reach their folders are not included through ancestor visibility. This visibility applies whether or not root settings are restricted to Site Administrators; it does not grant permission to change settings on an ancestor folder.

The configuration details shown depend on where the user's administrative permission starts. Only Site Administrators and users with admin permission at or above the folder where a setting is configured can access its administrative configuration. A Folder Admin whose permission starts below that folder receives a limited view that omits protected credential fields. This lets them understand inherited rules without receiving credentials for integrations they do not administer.

Folder admins can manage permissions for their folder by assigning or removing permissions for other users and groups, or by managing permission fences for the folder. They cannot add or remove their own folder permissions. Because they can only manage folder permissions, they cannot create, change, or remove groups or other users.

Folder Admins can view permission records for the folders they administer and all subfolders, including grants to other users, groups, and Partners. Grants on ancestor folders, including the site root, are visible only when they are recursive and apply to a folder the Folder Admin administers. Non-recursive ancestor grants are not included. The records let Folder Admins review inherited access affecting their folders. Folder Admin authority alone does not expose permission records on sibling folders or unrelated branches, and seeing an ancestor's permissions does not grant authority to change them or access that folder's contents.

Folder admins can view and manage other users' email notifications for the folders they administer. Their notification list includes notifications configured on folders above theirs in the same Workspace, including that Workspace's root, only when they are recursive and their scope includes a folder the Folder Admin administers. Non-recursive ancestor notifications and notifications whose scope does not reach their folders are not included through ancestor visibility. This list visibility does not grant permission to edit or delete another user's notification on an ancestor folder.

An email notification on the Default Workspace's site root never covers activity in a Custom Workspace. Administering folders in a Custom Workspace therefore does not expose Default Workspace notifications through ancestor visibility, including when a Default Workspace user has Workspace Administrator access to that Custom Workspace.

Folder Admins can see all users and groups on the site so they can assign permissions and configure notifications, including users and groups that do not currently have access to their folders. This is intentional directory visibility; it does not grant account-management authority or access to files outside their permissions.

Unlike other permissions, the folder admin permission is always recursive, granting administrator level access for all sub-folders.

Site Administrators do not have permissions assigned for any folders, so a Site Administrator cannot also be a folder admin. They have unlimited access to every folder in their site regardless.

Billing Administrator

Users can be designated as a Billing administrator in the user's settings. A billing administrator can see billing information, invoice history, and usage data. Billing administrators can open tickets with our support team, but they cannot grant site access to the support team.

Making a user account a billing administrator does not grant access to any files or folders.

Site Administrators are automatically billing administrators because they already have access to everything for a site, including billing information.

Administrative Access by Responsibility

Choose access for the work a person owns and the data they are trusted to reach. Someone responsible for site-wide authentication and security settings needs Site Administrator access. Someone managing a team's file flows, Partners, and integrations can instead administer that team's Workspace, with full access to its files but no authority over unrelated Workspaces or site-wide settings.

A team lead maintaining membership can be a Group Admin with the necessary user-management capabilities enabled by the site. Group-level folder permissions give members their file access. Grant Folder Admin permission separately when the lead also needs to manage a folder's settings and permissions; group administration does not confer that authority.

For support staff reviewing logs and configuration without changing them, Read-only Site Administrator access provides site-wide visibility. Supporting one department does not limit what that account can read. Someone who only handles invoices and usage can receive Billing Administrator access without file permissions.