Workspaces

A Workspace is an isolated resource and administrative boundary within a Files.com Site. It can organize a task, functional area, project, or team, with its own Users, Files, Remote Servers, Automations, and Partners. The same IT team can administer several Workspaces, or administration can be delegated within each one.

Every site starts with a Default Workspace. A site can run entirely there using users, groups, and folder permissions. Additional Workspaces keep related resources and flows together, whether or not they need different administrators. Account Structure & Environments helps you choose boundaries around function, access, ownership, and lifecycle before creating resources.

As an organization scales on Files.com, the volume of users, permission changes, automations, remote servers, and partner onboarding requests outgrows what a central administrative layer can absorb, and resources from different teams tangle together. A Workspace gives a team its own administrator and its own resource boundary while keeping site-wide governance centralized.

Site Administrators create Workspaces and designate one or more Workspace Administrators to run them. The Workspace Administrator handles their team's day-to-day operations on a self-service basis: onboarding users, managing partners, configuring automations, and setting up Remote Servers. Their authority is limited to the Workspaces they administer. Site Administrators can grant Default Workspace users administrative access to more than one Workspace; see Workspace Access and Administration.

Security policy, SSO, audit logs, branding, and billing are configured site-wide. Site Administrators manage domains and IP addresses, while a Custom Domain's Workspace availability determines which Remote Servers can select its outbound addresses.

Organizations create and manage Workspaces through the Web App, CLI, SDKs & APIs, and Terraform. There is no cap on the number of Workspaces a Site can have.

Resource Boundaries in Practice

A supplier-exchange team can keep its partner folders, users, Remote Servers, and Automations in one Workspace, with a Workspace Administrator responsible for that work. A payroll team can have another. Choose the boundary around the resources each team is trusted to administer, rather than recreating every department or region as a Workspace. Site Administrators retain access across all Workspaces.

A temporary project can use the same arrangement: keep its files, external Partners, connections, and flows together, grant access to the people involved, and plan what to retain when the project ends. A Workspace restricts ordinary users and its administrators to their granted scope; it does not hide the project from Site Administrators. Account Structure & Environments covers cleanup and retention before removal.

For unattended work, choose the execution identity as well as the Workspace. AI Tasks and Automations v2 use their owning site or Workspace's permissions. An external application uses its authenticated account or API key. A folder mentioned in a prompt or script does not establish an access boundary.

A test Workspace can separate an experiment's resources while sharing site settings. Use test data, credentials, and destinations: a test connection can still point at a production server. Choose a Child Site when the test requires independent SSO, security policy, domains, or IP addresses.

Comparing Workspaces to Related Features

Choose the boundary according to which resources and flows belong together and what needs separate administration. A team that only needs access to shared folders can use users, groups, and folder permissions within the Default Workspace. For detailed guidance on choosing between these features, see Account Structure & Environments.

Workspaces vs. Child Sites

Child Sites provide separate site configuration and resources under Parent Site administration, with their own Site Administrators, authentication configurations, IP addresses, custom domains, and branding. Granting Child Site Administrator access does not remove a parent-site account from parent-site account management. Choose Child Sites when regions, environments, or business units need separate site-wide configuration. Storage regions can also be assigned to folders within a site; storing a folder in a different region does not by itself require another site.

Workspaces provide operational isolation within a shared site infrastructure. Choose Workspaces to organize related resources and flows or delegate administration while sharing the same security policies, domain, and branding. Both can be used together. Child Sites separate site-wide configuration, while Workspaces organize resources and administration 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 users, partners, automations, and integrations within their assigned Workspaces.

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 manage users inside a single group. Site Administrators decide site-wide which user-management capabilities Group Admins can use, drawn from 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. Group Admins cannot manage folders, remote servers, automations, or partners. Use a Group Admin to delegate user management within one group; use a Workspace Administrator when delegation has to span users, folders, automations, partners, and integrations together.