Account Structure & Environments

Choose an account structure around the resources that belong together and the settings that need to differ. Files.com provides folders and permissions, Workspaces, Partners, and Child Sites for different parts of that design. User count alone does not determine which combination you need.

Begin with the Scope of the Work

Every site starts with a Default Workspace. A team sharing documents can use folders, individual users, groups, and folder permissions there. A Group Admin can maintain the team's membership within the capabilities the site permits; a Folder Admin can administer a folder. Neither role requires creating another organizational layer.

Use an additional Workspace to group related folders, users, Partners, connections, and flows. Payroll transfers, supplier EDI, and reporting can each have a Workspace managed by the same IT team. One task can justify a Workspace when keeping its resources together makes its access, operation, and lifecycle clearer. Several related flows can also belong together.

Choose that grouping before creating resources. A new Workspace starts empty; it does not automatically reorganize existing configuration.

Place Identities Deliberately

Users created in a Custom Workspace are scoped to it. For employees who work across several Workspaces, Site Administrators can grant cross-workspace access to users or groups from the Default Workspace. Grant the required folder access, or Workspace Administrator access when they need to administer the Workspace.

Create a Partner for an external organization in the Workspace responsible for the relationship. Its users share the Partner's permissions and cannot receive individual folder permissions or join groups. If an external application must access several Partners' areas, use the documented regular-user exception with carefully scoped folder permissions.

Plan account creation, credential ownership, and removal together. User Onboarding & Offboarding covers those lifecycle steps.

Separate Site Settings When Necessary

Workspaces share authentication configuration, site security policy, domains, network addresses, and branding. Use Child Sites when those settings need independent configuration. Parent Site Administrators retain oversight; a Child Site is not a boundary that excludes them.

Child Sites require an eligible plan and have plan-specific limits. Check those limits before making them part of an environment design. User Management Across Parent and Child Sites explains where to maintain identities and how cross-site access differs from an ordinary connection between sites.

Regional storage is another decision. Folder regions can place native files in different regions within one site; a regional file-storage requirement does not automatically require a Child Site.

Design Test and Production Environments

A test Workspace can isolate the resources for a folder-layout or transfer experiment while sharing site settings. A Child Site fits testing that must include independent SSO, security policy, domains, or other site-level configuration. Choose the boundary for what you need to test.

In either case, configure separate test credentials and destinations. A connection inside a test environment can still point to a production server. Check its host, account, and path before running it. Use representative test data without importing unnecessary production information.

Record who maintains each environment and how tested configuration reaches production. Shared resources such as Schedules can affect several Workspaces at once, so include their dependents in change review.

Plan the End of the Environment

Give temporary environments an owner and a removal date or condition. Stop scheduled work and retain any required files, logs, and configuration before cleanup. Workspace deletion and Child Site removal have different procedures; follow the one for the environment you created.