Administrative Roles

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.

Each administrative role grants a clearly scoped set of capabilities. Some roles 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 an administrative role 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 role and 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 authority granted by the role.

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 the role 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.

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. Workspace Administrators cannot access or modify anything outside their Workspace, including other Workspaces, main site resources, or site-wide settings. 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 the Workspace Administrator role, or by promoting an existing user from the main site (default Workspace) to Workspace Administrator for a specific Workspace. Workspace Administrators can also designate additional Workspace Administrators within their own Workspace by creating a new user with the role or by promoting an existing Workspace user.

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 the Partner Admin role. 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 role's basic account-management powers. 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, and exempting individual users from User Lifecycle Rules. Account changes apply only to users whose Primary Group they administer. Membership management can add or remove eligible members of their groups regardless of the user's Primary Group.

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, including the site 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.

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.

Read-only Site Administrator

A Read-only Site Administrator sees exactly what a Site Administrator can see, nothing less. The role 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 this role; 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 the role 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 the role combines with separately granted permissions to make changes.

Accounts with this role 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. Assigning this role does not remove those permissions.

To assign the role 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 the role.

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.

Demonstration Use Case

In this scenario, we have a mortgage broker that needs to assign the appropriate administration privileges for their Files.com site.

The mortgage broker operates from two branches (central and east). Carter is the head of IT and works out of the central office. Ellen is a help desk technician stationed in the east office. Each office has a sales team, a processing team, and a client services team, and each of those teams has a designated team leader. Chale handles all vendor payments and works from the central office.

Carter, as the head of IT, is a Site Administrator for the Files.com site. Carter can update any setting or file within the site, create users and groups directly, or set up automatic provisioning.

As the business grows, the mortgage broker opens a new division for commercial lending. Carter creates a Workspace for the commercial lending division and designates Morgan as the Workspace Administrator. Morgan can now onboard and offboard users, manage groups and partners, configure automations, set up remote servers, and apply folder permissions within the commercial lending Workspace on a self-service basis. Morgan cannot see or access anything in the central or east branch operations, and Carter retains full visibility across all Workspaces.

Carter defines user groups representing each team at each office and assigns users into their teams. Carter can assign folder permissions to a group to give each member a base level of access to specific folders, and can assign team leads admin-level access for specific folders.

Carter designates the team lead users as group admins for their respective groups. As group admins, they can add new users directly to their groups. With folder permissions assigned at the group level, this may be all the setup needed to create user accounts for new team members.

Ellen helps the staff of the east office when they run into a technical problem, so she needs to access log files and review how v1 Automations are configured. Carter makes Ellen a Read-only Site Administrator after confirming that she is trusted to read highly sensitive administrative information across the site. Her administrative visibility is not limited to the east office she supports.

Because Chale is responsible for vendor payments, Carter creates a user account for Chale that is not assigned to any department team and has no access to files or folders. Chale's account is set as a billing administrator, letting him access the invoices for the Files.com site.