Skip to main content

Workspaces

Workspaces provide isolated, self-contained environments within a Files.com Site for departments, business units, teams, and projects. Each Workspace contains its own scoped set of resources, including User Accounts, Files, Integrations, Automations, and Partners, all fully isolated from the rest of the site and from other Workspaces.

Site Administrators create Workspaces and designate Workspace Administrators to manage them. Workspace Administrators handle day-to-day operations within their Workspace, including onboarding users, managing partners, configuring automations, and setting up Remote Servers. They do this without involving the Site Administrator and without seeing or affecting any other Workspace.

All Workspaces within a Site share the same site-wide settings, including IP addresses, domain names, branding, security policies, and authentication configuration.

There is no cap on the number of Workspaces a Site can have. Organizations can create and manage them through the Web App, CLI, SDK & APIs, and Terraform. Creating a new Workspace requires minimal setup, making Workspaces well suited for organizations that frequently onboard new teams, launch new projects, or reorganize business units.

Why Workspaces Exist

As organizations scale on Files.com, the number of users, automations, remote servers, syncs, and partner relationships grows. Managing all of these resources from a single administrative layer creates bottlenecks. Every new user, every permission change, every partner onboarding request flows through the same Site Administrators.

Resources from different teams overlap and become difficult to distinguish. Automations, remote servers, and folder structures that belong to one department become tangled with those of another, making troubleshooting harder and increasing the risk of misconfiguration.

Workspaces solve this through four core capabilities:

Delegated Administration

Each team, department, project, or business unit gets its own Workspace Administrator. They manage their own users, partners, automations, and integrations. The Site Administrator is no longer the bottleneck. Workspace Administrators operate with true self-service, handling onboarding, offboarding, and configuration changes on their own schedule without filing tickets or waiting for central IT.

Resource Isolation

Resources are grouped by business line and scoped to where they belong. Users, folders, automations, remote servers, file flows, integrations, and partner relationships within one Workspace do not mix with those in another. No cross-contamination. No overlapping configurations.

Contextual Visibility

Workspace Administrators and users can access only the resources within their Workspace. Resources do not overlap across Workspaces. File flows, automations, integrations, and partner relationships remain scoped to the Workspace.

Centralized Governance

Site-wide governance policies including security settings, and audit logging stay centralized under the Site Administrator. Workspaces delegate operational control without giving up governance. The Site Administrator retains full visibility and authority across all Workspaces while each department or business unit operates independently within their boundary.

Use Cases

Below are some examples of how Workspaces can be applied across different operational boundaries. Workspaces support use cases beyond business units, including projects, departments, compliance requirements, agentic workflows, and any scoped context where teams require independent control over their own resources.

Delegated Administration for Business Units and Departments

A financial services company with lending, insurance, and wealth management divisions gives each division a Workspace. Each division's Workspace Administrator onboards loan officers, underwriters, or advisors. They set up remote server connections to their own core systems, configure automations for their own file flows, and manage their own external partners. The central IT team focuses on site-wide governance instead of handling every access request.

A healthcare organization takes the same approach to keep clinical operations, research, and billing in separate Workspaces. Patient billing data never appears in the research Workspace. Research trial files never appear in the billing Workspace. When regulators or clients require proof of data separation, the organization demonstrates it at the platform level.

Regional or Geographic Control

A logistics company with distribution centers in North America, Europe, and Asia gives each region a Workspace. The regional IT lead in each location onboards warehouse staff on a self-service basis, connects to local EDI and ERP systems, and manages vendor relationships with local carriers and freight forwarders without waiting on the global IT team. Because all regions share the same security policies, authentication, and branding, Workspaces are the right fit. If the regions required separate IP addresses, custom domains, or different authentication configurations, Child Sites would be the better choice.

Simplifying Complex Permission Models

A media company with 15 departments previously relied on nested folder permissions, permission fences, and group-based access rules to keep teams separated. Over time the permission structure became difficult to audit and prone to misconfiguration. Moving each department into its own Workspace replaced hundreds of overlapping permission rules with clean, structural separation.

Independent Partner Management

An automotive manufacturer's procurement, engineering, and aftermarket divisions each work with different suppliers. Procurement exchanges purchase orders with parts suppliers. Engineering shares CAD files with design partners. Aftermarket sends catalogs to distributors. Each division manages their own partner relationships within their Workspace without creating confusion about who owns which partner.

Client Engagements and Project-Based Environments

A managed services provider runs file transfer operations for multiple enterprise clients. Each client engagement gets its own Workspace. The engagement lead manages their own users, automations, remote server connections, and partner access. One client's data, integrations, and file flows never intersect with another's.

A construction firm takes the same approach per major project, where the project manager onboards subcontractors, sets up automations, and connects to the project management system. When the project completes, the Workspace is no longer needed.

Rapid Onboarding of New Divisions or Acquisitions

A retail conglomerate acquires a specialty brand. Instead of restructuring the existing site, the IT team creates a new Workspace for the acquired brand. The brand's operations lead becomes the Workspace Administrator and builds out the folder structure, onboards staff, connects to the brand's fulfillment systems, and sets up partner relationships from day one.

Agentic and Automated Workflows

Organizations building agentic workflows or AI-driven automations use Workspaces as secure, isolated execution environments. Each agent or automated process operates within a Workspace boundary, with access only to the folders, integrations, and partner connections within that Workspace. The agent cannot read, modify, or interact with data in any other Workspace or on the main site. This isolation ensures that automated processes operate within well-defined boundaries without the risk of accessing or modifying unrelated data.

Testing and Experimentation

A Site Administrator creates a temporary Workspace to test new automations, validate remote server connections, or experiment with folder structures and file flows before rolling them out to a production Workspace. Because creating a Workspace requires minimal setup, teams can spin up a test environment, run their validation, and remove it when done without affecting any production resources.

How Workspaces Compare To Other Organizational Features

For most organizations, Workspaces provide a more complete delegation model. For detailed guidance on choosing between these features, see Child Sites, Workspaces, Partners, and Admin Permissions: When To Choose Each.

Workspaces vs. Child Sites

Child Sites provide full site-level isolation with separate Site Administrators, authentication configurations, IP addresses, custom domains, and branding. Choose Child Sites when you need data residency requirements (for example, EU data must stay in an EU region), regulatory compliance boundaries that require separate governance, different security policies, or environment separation (production, staging, development).

Workspaces provide operational isolation within a shared site infrastructure. Choose Workspaces when teams need independent administration but share the same security policies, domain, and branding. Both can be used together. Child Sites handle hard separation. Workspaces handle internal delegation within each site.

Workspaces vs. Partners

Partners represent external organizations, including clients, vendors, and suppliers. Partners exist within a Workspace, which allows Workspace Administrators to manage their own external relationships. Workspaces organize internal operations, while Partners organize external relationships.

Workspaces vs. Site Administrators

Site Administrators have full access to everything on the site, including all Workspaces, site-wide settings, billing, security, and authentication. Making someone a Site Administrator to manage a single department or business unit grants them access far beyond what they need. Workspaces solve this by giving that person full operational control within a defined boundary. A Workspace Administrator manages their own users, partners, automations, and integrations without seeing or affecting anything else on the site.

Workspaces vs. Folder Admins

Folder Admins manage folders and folder settings for a specific folder. They cannot manage users, groups, remote servers, or partner relationships. Folder Admins are a tactical permission tool, not an organizational layer. Use Folder Admins within a Workspace to give someone limited control over a specific folder without full Workspace administration.

Workspaces vs. Group Admins

Group Admins can create users within their assigned groups but cannot manage those users after creation, and cannot manage folders, remote servers, automations, or partners.