Delegated Administration
Group Admins and Partner Admins let the people responsible for a team or an external organization handle its day-to-day user administration. They can onboard users, maintain accounts, help with sign-in, or end access without becoming Site Administrators. Site Administrators and Workspace Administrators choose who receives these roles and retain control over the resources the group or Partner can access.
Delegating account management gives someone influence over who can use that access. A person who can add members, change sign-in details, or re-enable accounts can affect access to your files even without permission to change folder permissions. Choose the role and its capabilities together, based on the accounts and resources you trust that person to manage.
Group and Partner Boundaries
Group Admins manage internal teams organized into groups. Account-management authority follows each user's Primary Group: an administrator of that group can perform the account actions you enable. Membership management is separate. When enabled, it lets a Group Admin add or remove members of the groups they administer, even when those users have a different Primary Group.
A user can belong to several groups but has at most one Primary Group. Changing or disabling that user's account affects their use of Files.com across all their permissions, including access obtained through other groups. Primary Group identifies who manages the account; it does not confine the account's access to that group's folders.
Partner Admins manage external users within one Partner. All Partner Users inherit the Partner's folder permissions and remain within its Root Folder. They cannot belong to groups or hold Site Administrator or Workspace Administrator roles. A Partner Admin can change an individual user's File System Layout to show a subfolder or restore the full Partner Root view. That individual layout is therefore under the Partner Admin's control; the Partner's Root Folder and permissions remain the limit the administrator cannot expand.
Neither role by itself grants permission to administer folders, change the site's security policies, or directly assign administrator roles to other users. Site Administrators and Workspace Administrators make role assignments within their respective scopes. Group Admins may separately hold folder or other administrative permissions; assess those additional permissions alongside their delegated user-management role.
Choosing Group Admin Capabilities
A Site Administrator controls Group Admin capabilities site-wide. Changing a capability affects every Group Admin, including those appointed by Workspace Administrators. User creation is enabled by default; the other capabilities below are disabled by default.
| Capability | What you are delegating |
|---|---|
| Create users | Onboarding new accounts into groups the administrator manages. The new user's Primary Group is one of those groups, and the user receives the group's access. |
| Add or remove existing users | Deciding who receives the access already assigned to the group. This also lets the Group Admin search the site's user directory to find existing accounts. Eligible users must belong to the group's Workspace; Partner Users cannot join groups. |
| Edit users | Maintaining identity and profile information, including email address and username, and changing account expiration, sign-in options, and FTP/SFTP root and home folders. Email editing also controls the destination for password recovery. |
| Enable or disable users | Suspending an account or restoring its access. Re-enabling an account also restarts the inactivity period used by User Lifecycle Rules. |
| Delete users | Removing accounts whose Primary Group the administrator manages. Deleting an account does not automatically remove its stored files or every resource it created. |
| Set or reset passwords | Changing passwords for managed accounts, resetting enrolled 2FA methods, and resending welcome emails. This gives the administrator direct control over credentials and second-factor enrollment. |
| Select Password authentication | Choosing the Password authentication method, including for new accounts. Changing an existing user's password also requires the password-reset capability. |
| Exempt users from User Lifecycle Rules | Keeping selected accounts from being automatically disabled or deleted by those rules. This does not remove a separate access expiration date. |
Enabling or disabling users, resetting passwords, and exempting users from lifecycle rules each require the edit capability as well. User creation, membership management, and deletion have their own controls; editing alone does not grant them. Editing allows the Email signup authentication method, while selecting Password has the separate control shown above. Group Admins cannot directly change a user's Primary Group, Site Administrator status, or 2FA requirement.
Treat editing as authority over the account, including its access. An editor can change its recovery address, choose Email signup, or set an access expiration date. Withholding direct password resets or the enable/disable control does not remove those effects of editing.
Membership Is an Access Decision
A Group Admin does not need permission to edit the group's folder permissions to give another user that group's existing access. Review what membership conveys before enabling creation or membership management. This includes Folder Admin permissions and any Workspace Administrator or Child Site administrator access assigned to the group. Also consider protocol access and any administrator roles assigned through your SSO group-provisioning rules.
Removing someone from one group removes access obtained through that membership. It does not disable the account or remove permissions obtained directly or through another group. Conversely, disabling or deleting an account through Primary Group administration affects the whole account. Choose membership removal when someone leaves a project; review all access when the person leaves the organization.
Choosing Partner Admin Authority
Partner administration gives an external organization responsibility for its own users while the hosting site's administrators control the Partner's Root Folder and permissions. Unlike Group Admin capabilities, the optional Partner Admin Settings apply separately to each Partner.
Powers Included in the Role
A Partner Admin can edit, enable, disable, and delete accounts within their Partner even when all optional Partner Admin Settings are disabled. Account editing includes email addresses, usernames, profile details, authentication methods, access expiration, and folder layout. Partner Admins can also resend welcome emails. Assign this role only to someone you trust to maintain the organization's accounts and decide whether existing users should retain access.
Partner Admins can manage Additional Email Recipients for their users. These recipients receive copies of eligible account and notification emails, so this authority can disclose information about the Partner's activity to additional people. Password recovery, welcome emails, email verification codes, and emails containing signed download links go only to the primary recipient. A Partner Admin cannot choose the internal Responsible Party assigned to a user or to the Partner.
Partner Admins can initiate, view, and cancel pending Connected Site requests. A Site Administrator at the invited Files.com site must approve a connection. Once approved, every Site Administrator on that Guest Site can access the Host Site through the Partner's folder permissions; ordinary Guest Site users do not receive that access. Review the invited organization as well as the individual accepting the invitation. Disconnecting an established connection requires a Site Administrator on either site.
Partner Admins can view relevant policies, including 2FA requirements and User Lifecycle Rules, so they can understand the conditions governing their users. They cannot edit those site policies or grant themselves broader Partner permissions.
Optional Partner Capabilities
| Partner Admin Setting | What you are delegating |
|---|---|
| Allow user creation | Adding new accounts with the Partner's existing folder access. The Partner Admin decides who else in the organization receives that access. |
| Allow credential changes | Setting passwords, resetting enrolled 2FA methods, and managing SSH keys for Partner Users. Trust the administrator to manage how those users authenticate, including credentials that can be used to sign in as them. |
| Allow bypassing 2FA | Overriding the site's 2FA requirement for individual Partner Users. This can let a user sign in without the second factor the site would otherwise require. |
| Allow providing GPG keys | Managing the Partner's GPG keys for encrypted file exchange. Folder Admins still configure folder encryption or decryption; the Partner Admin supplies and maintains the key material those workflows depend on. |
Keep the two 2FA-related settings distinct. Resetting enrolled methods changes which second factor a user can present; overriding the requirement changes whether the user must present one. Turning off all four optional settings does not remove the account-management powers included in the Partner Admin role.
When delegating GPG key management, coordinate key replacement with the administrator responsible for the file-processing workflow. The selected public key determines who can decrypt encrypted output, while decryption depends on the matching private key. Changes to keys used by a workflow can affect both its recipients and its ability to process files. Follow the GPG Key Manager guidance when replacing or retiring keys.
Email, Passwords, and Second Factors
An account's primary email address is also its password recovery channel. A Group Admin with editing enabled, or any Partner Admin for that user's Partner, can change that address. When email recovery is enabled for a password-based account, the administrator can direct a recovery link to a mailbox they control and use it to set a new password, even without permission to change passwords directly. Granting control over email addresses therefore also delegates control over this route to account recovery.
Password recovery does not remove enrolled 2FA methods. Signing in still requires the user's second factor and the normal sign-in checks. An authenticator app or hardware key provides a check independent of the mailbox; email verification relies on that same mailbox. If you rely on this separation, review the administrator's ability to reset enrolled methods and, for Partner Admins, override the 2FA requirement.
SSO users recover access through their identity provider. Users configured for Email signup receive a signup email instead. Disabling the site's Password recovery via email setting stops email password recovery and invalidates outstanding recovery links, but does not remove delegated email editing, permitted authentication-method changes, or direct credential management.
Changing an email address invalidates outstanding recovery links and ends the user's other active sessions. A user changing their own address keeps the session making the change; an administrator changing another user's address ends that user's active sessions. No change notice goes to the previous address. A later password-changed notice goes to the current address, so the previous mailbox is not an independent record of administrative changes.
Reviewing and Ending Delegation
Keep delegated administration consistent with your SSO and provisioning controls. Restrictions on manual user or group management still apply. Decide whether account and membership changes belong in Files.com or in your identity provider so the two management processes do not work against each other.
Review account, membership, and administrative configuration changes through Settings Changes. Site Administrators and Read-only Administrators can use that history to check which accounts were created, which memberships changed, and which settings were modified. Review the current configuration as well as the history: the effect of a membership or credential change depends on the access the account holds now.
Removing the Group Admin or Partner Admin role ends that delegation; it does not undo changes already made. Review accounts created or re-enabled, group memberships, recovery addresses, credentials, lifecycle exemptions, additional email recipients, and any Connected Site access the administrator arranged. Remove separately granted administrative permissions if they are no longer needed.
Disabling or deleting a user ends that account's access but does not delete its stored files. Share Links remain available unless revoked or covered by the site's automatic revocation setting, and user-owned workflows may need reassignment. Include those resources in offboarding so ending someone's administrative role also produces the access and operational result you intend.