Child Sites, Workspaces, Partners, and Admin Permissions: When To Choose Each

Child Sites, Workspaces, and Partners give Files.com one of the most flexible organizational models in the file integration and managed file transfer space. That flexibility raises a practical question: when do you use child sites, when workspaces, when partners, and how do these relate to folder admins and group admins?

This page answers that question, including why each feature exists, what it is designed for, and how to combine them without painting yourself into a corner.

Files.com Is Flexible By Design

Files.com is deliberately flexible, not prescriptive. This page outlines best-practice guidance, but you are not required to follow it rigidly. If a different structure better matches your operational reality, that is perfectly valid.

We do encourage customers to think through these decisions intentionally and, when in doubt, to review them with your onboarding or account team. A small amount of upfront design saves significant operational friction later.

Feature Names Are Intentional

One of the guiding philosophies at Files.com is that feature names reflect intended use. This matters more than it may seem.

Customers sometimes ask whether the Partners feature is a good way to organize internal departments. While that might work in a purely technical sense, it is not what Partners is designed for, and the name tells you that. Partners is optimized for external third-party counterparties: customers, vendors, suppliers, and trading partners. The feature will continue to evolve in ways that benefit external relationships, not internal organizational models. We are unlikely to add enhancements to Partners that support internal user management.

By contrast, Workspaces are intentionally named to be neutral and flexible, Child Sites support a wide range of organizational patterns, and Folder Admins are exactly what they sound like — administrators of a folder — and are unlikely to evolve beyond that scope.

Understanding this naming philosophy helps you make decisions that age well as the platform evolves.

The Fixed Organizational Hierarchy

All of these features operate within a strict, permanent hierarchy. This hierarchy will not be reversed or reshaped in the future, so it is essential to understand it clearly:

Sites (Main Site + Child Sites) → Workspaces (Within a Site) → Partners (Within a Site or Workspace) → Users (Within a Site or Workspace or Partner)

Some key implications:

• A workspace can never span multiple sites.
• A partner can never belong to more than one workspace.
• Users other than site admins are scoped to a single workspace.

This structure is fixed and foundational. Nearly every design decision starts by acknowledging this hierarchy.

Child Sites

Child Sites sit at the highest level of organizational separation and are the right choice when you need hard boundaries between environments.

Consider child sites when you need different primary infrastructure or identity (geographic regions, custom domains, or branding such as logos, colors, login pages, and emails). Each site has its own IP addresses and custom domain configuration, and those cannot be shared or merged across sites.

Child sites also fit when you need different site-wide security or compliance settings: encryption required vs. optional, HIPAA / BAA vs. non-PHI environments, or other site-wide policy differences that must be enforced universally.

Environment Separation (Prod / Staging / Dev)

Many customers use child sites to separate Production, Staging, Development, and UAT / NPE / Test environments. This is common for two reasons.

The first is network controls. Separate IP addresses make it easier to enforce firewall rules, traffic isolation, and logging guarantees.

The second is visual safety. Customers often apply dramatically different branding, banners, or warnings to non-production environments to prevent costly mistakes.

It is possible to model environments using workspaces or folders, but child sites are generally the cleanest and safest approach when those distinctions matter.

Cost Considerations

Child sites require an Enterprise plan and are metered and billed. For most customers already on an Enterprise plan, we are able to include enough Child Sites to meet your needs for little to no additional cost.

Workspaces

Workspaces are the primary organizational tool inside a Site and are designed for delegated administration at scale.

All workspaces within a Site share all of the sitewide settings, including the same IP addresses, domain names, and branding. Each workspace is otherwise a self-contained operational universe, with its own users, groups, partners, files, folders, folder settings, remote servers, syncs, mounts, automations, and AS2.

Default Workspace Behavior

Before workspaces are enabled on a Site, everything lives in the default workspace (Workspace ID 0). Once new Workspaces are enabled, new resources can be created in the new workspaces.

Ideal Use Cases For Workspaces

Workspaces fit internal departments, business units, client engagements, confidential projects and M&A diligence, and large-scale multi-tenant internal operations.

The Most Important Constraint

Only site administrators can operate across workspaces within a Site. All other users are locked to a single workspace and cannot see or manage resources outside of it.

For most customers using Workspaces — especially mid-market and enterprise — this is a feature, not a limitation. It produces clean separation of responsibility, safe delegated administration, scalable automation via API, and clear operational ownership.

Cost Considerations

Workspaces are unmetered and unlimited, and can be created and destroyed freely via the web app, API, and SDKs like Terraform. This makes them ideal for dynamic, high-volume organizational models.

Partners

The Partners feature adds one more layer of delegation, specifically designed for external business relationships. A Partner represents a third party that trades with your business, such as a customer, vendor, supplier, or trading partner.

Why Our Partners Feature Exists

Partner onboarding and management is consistently cited as one of the biggest pain points in traditional MFT systems. Onboarding takes too long, supporting partners is manual and error-prone, and self-service is limited or nonexistent. Partners was built to solve all three problems.

The feature provides a single scoped permission model per partner, partner-managed user creation and password resets, partner-managed encryption key uploads, clean user jailing and route scoping, and faster onboarding with less internal effort.

Unique Capabilities Exclusive To Partners

Partners unlock functionality that does not apply to Workspaces.

Site-to-Site Partner Linking: if your partner also uses Files.com, they can link their own Site directly for single sign-on between their Site and their access to your Site. This does not grant additional access, but it dramatically improves their operational visibility and management.

Automated Partner Onboarding (Coming Soon): Files.com is introducing automated onboarding workflows for Partners, including automated acceptance tests, send/receive validation, and self-service partner verification. These capabilities live inside the Partners feature, not workspaces, because they are designed for external counterparties.

Cost Considerations

Partners can be created and destroyed freely via the web app, API, and SDKs like Terraform. This makes them ideal for dynamic, high-volume customers. We will soon be capping the number of Partners that can be added on our Starter and Power plans, and we do intend to create a billing apparatus around them similar to Users.

How Folder Admins And Group Admins Fit In

Folder Admins and Group Admins are tactical permission tools, not organizational layers.

Folder Admins manage folders, and that is all they are designed to do. They are useful within Workspaces or Child Sites.

Group Admins delegate user management within a single group. Site Administrators decide site-wide which user-management capabilities Group Admins can use, drawn from creating users, editing user details, enabling or disabling accounts, deleting users, setting and resetting passwords, and exempting individual users from User Lifecycle Rules. Group Admins are useful when a group lead handles onboarding and maintenance for their team without taking on Workspace administration.

With recent additions like Child Site Management Policies, and continued investment in Workspaces and Partners, many customers will restructure their deployments to take advantage of these capabilities — and in doing so, unlock faster onboarding, clearer ownership, and far more scalable file operations.