Managing Workspaces

Only Site Administrators can create or remove Workspaces. When a Site Administrator creates a Workspace, the Workspace gets its own root folder automatically.

Workspaces can be created, updated, and deleted through the Web App. They can also be provisioned automatically as part of onboarding workflows or infrastructure-as-code practices through the API/SDKs, CLI, and Terraform.

Assigning Workspace Administrators

After creating a Workspace, the Site Administrator designates one or more Workspace Administrators to manage it. The Site Administrator can:

• Create a new user for the Workspace and assign the Workspace Administrator role to them. This is common when onboarding a new business unit, department, or team onto the Files.com site.
• Promote an existing user on the main site to the Workspace Administrator role.
• Assign the Workspace Administrator role to a user who is already a Workspace Administrator for another Workspace. A user can be a Workspace Administrator for multiple Workspaces and can switch between them independently.

Site Administrators do not need to be designated as Workspace Administrators because they already have full access to all Workspaces.

User Access and Workspace Root Folder

When a Workspace is created, the Site Administrator or Workspace Administrator creates users, groups, and partners within that Workspace. These users, groups, and partners exist only within that Workspace and cannot see or access resources outside of it.

The Workspace Root folder restricts all Workspace users to one section of your site and prevents them from accessing anything outside of the Workspace Root folder path. When a Workspace user connects, they see the Workspace Root folder as the top level of the site. This restriction applies regardless of how the users connect, whether through the Web App, API, Desktop App, Mobile App, FTP, SFTP, WebDAV, or CLI.

Workspace Administrators have full administrative access to all folders within the Workspace Root. They assign folder permissions to Workspace users, groups, and partners. Permissions can only grant access to folders within the Workspace Root. Users, groups, and partners within a Workspace have access only to folders that the Workspace Administrator has explicitly assigned to them.

Site Administrators can also assign folder permissions on any Workspace folder to any user on the site, including standard users on the main site. When a standard user on the main site receives a folder permission on a Workspace folder, they continue to see all their main site resources when they log in. To access the Workspace folder, they switch to that Workspace after logging in. A user can receive folder permissions from more than one Workspace.

Default Workspace

Before Workspaces are enabled on a Site, all existing resources (files, folders, users, groups, partners, automations, remote servers, syncs) live in the Default Workspace, which is the main Files.com site.

When a Site Administrator creates a new Workspace, it starts as a clean slate. No files, folders, users, groups, partners, automations, syncs, or integrations carry over. The Workspace Administrator builds out the environment from scratch, creating the folder structure, onboarding users and partners, and configuring automations and integrations for their team, department, or business unit.

Creating a new Workspace does not move or remove any existing resources from the main site. All existing files, folders, users, groups, partners, automations, and integrations on the main site remain unchanged.

What a Workspace Contains

The Workspace Administrator or Site Administrator can create and configure the following resources within a Workspace on a self-service basis. All resources are scoped to the Workspace and isolated from other Workspaces and from the main site.

Storage and bandwidth usage, site-wide security settings, SSO, logging and audit trails, SIEM, billing, branding, and custom domains are managed at the site level and are not configurable within individual Workspaces.

What Workspace Administrators Can Manage

Workspace Administrators manage all resources within their Workspace on a self-service basis. They do not need to involve the Site Administrator for day-to-day operations.

User Management

Creating individual users, bulk creating users through CSV import, resetting passwords, disabling and re-enabling accounts, offboarding users, setting access expiration dates, configuring protocol privileges, managing IP whitelists, and creating user lifecycle rules to automatically disable or delete inactive accounts.

Group Management

Creating groups, updating group memberships, and assigning Group Admins within the Workspace.

Partner Management

Onboarding and offboarding Partners, creating and managing partner users, designating Partner Admins, and configuring Partner Admin settings to control what Partner Admins can do within their Partner organization.

Folder and File Management

Creating folder structures, assigning and managing folder permissions for users, groups, and partners, designating Folder Admins for specific folders, applying folder settings including watermark previews, folder locks, and file organization rules (rename on upload, organize files), and configuring data governance policies including storage regions, retention policies (file expiration, archive/remove), and file restrictions (extension limits, name length limits, name regex limits).

Automations and Integrations

Creating and managing automations, remote servers, remote server mounts, and syncs. Workspace Administrators can configure these only on folders within their Workspace. They cannot create automations, syncs, or mounts on folders outside their current Workspace.

Sharing and Collaboration

Creating and managing share links, configuring share link permissions and expiration, creating inboxes for receiving files from external parties, setting up share groups, creating custom forms, and configuring public hosting for Workspace folders.

Security Keys

Creating and managing SFTP/SSH keys and GPG keys for Workspace users, revoking keys, and applying key lifecycle rules to automatically expire or rotate keys.

AS2

Creating and managing AS2 identities, configuring AS2 trading partners, and managing AS2 certificates for Workspace-level B2B file exchanges.

Notifications

Creating and managing email notifications, webhooks, Amazon SNS notifications, Google Pub/Sub notifications, Slack notifications, and Microsoft Teams notifications for events within the Workspace.

What Workspace Administrators Cannot Manage

Workspace Administrators do not have access to anything outside their Workspace. The following remain under the exclusive control of Site Administrators:

• Site-wide security and protocol settings, including FTP, SFTP, and WebDAV configuration, ciphers, host keys, certificates, and 2FA requirements.
• Authentication, including SSO provider integrations and site-wide authentication configuration.
• Monitoring and logging, including SIEM integrations, site-level logs, and usage reporting.
• Billing and site administration, including billing, Workspace creation, child site creation, and clickwraps.
• Site customization and infrastructure, including custom domains, site branding, custom SMTP, and all other site-level customization.
• Recovery and integrity, including restoring deleted files, folders, or users, and checksum and file integrity settings.

Delegating Administration Within a Workspace

Workspace Administrators can further delegate administration within their Workspace by assigning existing admin roles to Workspace users:

• Folder Admins can manage folder settings and permissions for specific folders within the Workspace.
• Group Admins can create users within their assigned group inside the Workspace.
• Partner Admins can manage users within their Partner organization inside the Workspace.

This allows the Workspace Administrator to distribute onboarding, offboarding, and day-to-day management responsibilities across their team without giving every user full Workspace administration.

Customizing Left Menu Visibility

Site Administrators can control which sections of the Files.com interface are visible to Workspace Administrators and standard users. This is a site-wide setting that applies across all Workspaces and the entire site. Sections that can be shown or hidden include Sharing, Automations, Integrations, Notifications, Client Apps, and Developers.

Accessing Workspaces

Site Administrators access Workspaces by switching between them from the Web Interface. Workspace Administrators and Workspace users see only their assigned Workspace when they log in.

Site Administrators can specify a Workspace context on API requests by including the Workspace ID. This scopes the request to that Workspace's resources without removing the Site Administrator's broader authority. Workspace Administrators authenticate and interact with the API normally. Their API access is automatically scoped to their assigned Workspace.

The Files.com CLI supports Workspace access. Workspace Administrators and users interact with their Workspace resources through standard CLI commands, automatically scoped to their Workspace.

Workspaces can be provisioned, updated, and managed through the Files.com Terraform provider. This supports infrastructure-as-code workflows where Workspaces are managed alongside other site resources.

Users who belong to a Workspace access their Workspace files through FTP, SFTP, and WebDAV. The Workspace boundary constrains the visible file system to the Workspace root.

Workspace users access their Workspace files through the Desktop App and Mobile App. Users see only the files and folders within their assigned Workspace.

Deleting a Workspace

Only Site Administrators can delete a Workspace. When a Site Administrator deletes a Workspace, all resources inside that Workspace are deleted immediately. This includes files, folders, users, groups, partners, automations, remote server configurations, remote server mounts, syncs, share links, inboxes, notifications, webhooks, AS2 identities, SFTP/SSH keys, GPG keys, custom forms, and any other resources that were created within the Workspace.

This action is permanent and cannot be undone. Site Administrators should ensure that any data or configurations within the Workspace are no longer needed, or have been backed up, before deleting a Workspace.