Workspace Access and Administration

Site Administrators create Workspaces and designate one or more Workspace Administrators to run them. Workspace Administrators then handle all day-to-day operations within their Workspace on a self-service basis: creating and managing users, groups, and partners; configuring automations, syncs, and remote server mounts; applying folder settings; and managing data governance. See Workspace Administrators for the full list of what they can and cannot manage.

In addition to users created directly in a Custom Workspace by its Workspace Administrator, Site Administrators can give Default Workspace users cross-workspace access to one or more Custom Workspaces. This lets a Default Workspace user switch into a Custom Workspace without being reassigned to it.

Cross-Workspace Access for Default Workspace Users

Only Site Administrators can assign cross-workspace access. It applies only to Default Workspace users. A user who was created directly in a Custom Workspace cannot be given cross-workspace access to another Workspace.

To assign access, a Site Administrator opens the Workspace's permission settings and adds the user. When a user has cross-workspace access, a Workspace switcher appears in the Web App, Desktop App, Mobile App, and CLI. The user can switch into any Workspace they have access to and switch back to the Default Workspace at any time.

All standard folder permission levels are available when assigning a Default Workspace user to a Custom Workspace. A user can also be granted Workspace Administrator access, which gives them full administrative control over the entire Workspace rather than access to a specific folder. A user can have different access levels across different Workspaces.

Workspace Administrator access for a Default Workspace user is an Admin permission on the Custom Workspace's root folder. Admin permission on a subfolder provides Folder Admin access to that folder and its descendants, without authority to administer the Workspace's users, groups, Partners, or integrations. Choose the root grant when the person is responsible for the whole Workspace and a subfolder grant when their responsibility is limited to that folder.

While working in the Default Workspace, a user with the root Admin grant can see all of its users and groups through the same directory visibility as a Folder Admin. This supports selecting users and groups for folder permissions and notifications. The grant does not authorize administering Default Workspace accounts or groups.

Visibility into permission records, Folder Settings, and notifications on Default Workspace folders still follows the Folder Admin ancestor visibility rules. Seeing the directory does not expose all Default Workspace folder records. Ancestor records are visible only when they are recursive and their scope reaches a folder the user administers.

Cross-Workspace Access for Groups

Site Administrators can assign cross-workspace access to a Group from the Default Workspace. All members inherit the assigned permission level while keeping their existing accounts and Group membership in the Default Workspace. A Group created in a Custom Workspace stays within that Workspace.

To delegate administration to an existing team, assign Admin permission to its Group on the Custom Workspace's root folder through the Workspace's permission settings. Every member becomes a Workspace Administrator for that Workspace, with full access to its files and authority over its users, Partners, workflows, and integrations. Admin permission on a subfolder provides only Folder Admin access, just as it does for an individual user.

The Group can receive different permissions in different Workspaces. For example, an operations Group can administer a supplier Workspace and have Read access to a reporting Workspace. This keeps the team's membership in one place without making its members Site Administrators.

Adding or removing members changes the Workspace access they inherit from the Group, including when membership is maintained through SCIM. A Group Admin allowed to manage membership can therefore give others the Group's Workspace Administrator access. Choose who can manage membership with that authority in mind.

Removing a member or removing the Group's root Admin permission ends administration received through that grant. It does not remove permissions granted directly to the user or through other Groups. Review those other grants when withdrawing someone's access; a person can retain folder access after their Workspace administration ends.

The developer Workspace guide covers assigning these permissions through the API, SDKs, and CLI.

Moving a User to the Default Workspace

Site Administrators can move a user out of a Custom Workspace and into the Default Workspace from the user's details page. Select Move to Default Workspace from the More menu on the user details page.

This option appears only when viewing a user who is currently in a Custom Workspace, and moves in one direction only: from a Custom Workspace into the Default Workspace. Moving a user from the Default Workspace into a Custom Workspace is not supported through the Web App or the API.

Moving to the Default Workspace expands the scope in which the user can be granted access while preserving their existing access. The move does not grant access to every Workspace or folder; additional access still requires permissions.

The reverse move would restrict the user to one Custom Workspace. It would require identifying and removing any existing access or relationships outside that Workspace. The supported direction avoids taking away access or deleting resources the user already uses.

If you need to reorganize users across Workspaces or Child Sites as your use of Files.com grows, contact us to discuss the migration. Customer expansion needs help guide our priorities for additional migration tools.

Moving Workspace Administrators and Partner users to the Default Workspace is not supported. To move a Workspace Administrator, remove their Workspace Administrator access first. To move a Partner user, unlink them from their Partner organization first. Moving a user to the Default Workspace is also not supported on sites that do not allow local user creation (SSO provisioning-only sites), because the move performs a local user update.

Moving Files Between Workspaces

When using the Web App, files can be copied or moved between Workspaces. The Web App's Copy/Move source and destination pickers include a Workspaces tab alongside the standard folder tree.

Site Administrators see all Workspaces when operating from the Default Workspace. Users with cross-workspace access see only the Workspaces they have been given access to, and can only select Workspaces where they have write permission as a destination.

To copy or move files between Workspaces, operate from the Default Workspace.

When copying a folder between Workspaces, select Copy all folder settings to the new destination to copy its supported folder settings onto the destination folder tree. Folder copying through the API also supports copying these settings.

Workspace source and destination selection is also available in Automation and Sync configurations. Site Administrators see all Workspaces. Users with cross-workspace access see only the Workspaces they have been given access to, and can only select Workspaces where they have write permission as a destination.