Customer Isolation

Files.com separates customers' data and configuration while running on shared infrastructure. Access to one customer's site does not grant access to another customer's site. Each operation must be authorized for the site and resources it affects, including access to file contents and background work performed on the customer's behalf.

This is logical separation through access controls. Sharing a service or storage system does not give customers access to each other's data, and creating a Site or Workspace does not allocate dedicated physical infrastructure.

Site and Workspace Boundaries

A Site has its own users, resources, and site-wide configuration. A Site Administrator has full authority to manage the site, including all files, users, settings, integrations, and Workspaces. Folder permissions and Workspace boundaries do not limit that administrative role.

Child Sites separate site configuration and resources under central administration. Every Parent Site Administrator has full Site Administrator authority on every Child Site, regardless of who created it. There is no setting that removes or reduces that authority while the person remains a Parent Site Administrator. Child Site permissions and separate SSO configuration cannot exclude them. Child Site Management Policies do not remove their authority either, because Parent Site Administrators can change or remove those policies from the Parent Site. This is a fixed part of the Parent and Child Site design.

Keep Parent Site Administrator accounts to the minimum necessary and protect them with two-factor authentication and careful control of their credentials. Grant Child Site administration to people who need to manage only selected sites. The Child Site Administrator role does not grant access to the Parent Site or sibling Child Sites; the Parent Site Administrator role always carries authority over the whole hierarchy.

Workspaces provide resource and administrative boundaries within a Site. They share the Site's authentication configuration, security policies, and other site-wide settings. Site Administrators retain access across all Workspaces. Workspace Administrators have authority within the Workspaces they administer, and Site Administrators can explicitly grant users access to additional Workspaces.

These distinctions matter when evaluating separation between teams or environments. A Workspace separates delegated work within a common site policy; a Child Site separates site configuration while retaining the Parent Site's administrative relationship. Account Structure & Environments covers the choice between them.

Groups, Partners, and Folder Access

Groups collect permissions and let you manage access for a team; they do not create separate sites or independent security settings. A person can belong to several groups, and their user and group permissions combine. A group name alone is not a boundary around that person's total access.

A Partner defines an external organization's users, Root Folder, and folder permissions. Partner Users inherit that Partner's permissions, cannot belong to groups, and remain within the Partner's folder boundary. This is different from giving an internal group access to a folder while its members may also have other permissions.

Folder permissions determine access to content inside these organizational scopes. They are not a way to exclude a Site Administrator from their site or a Workspace Administrator from the Workspace they administer. Choose the administrative boundary before assigning content access when different teams must manage their own resources.

Deliberately Connected Sites

Separation does not prevent you from authorizing a connection between sites. A Connected Site exposes a Host Site Partner's folder access to Site Administrators of the approved Guest Site. The relationship grants that defined access; it does not merge the sites' users, settings, or ordinary user permissions.

A Files.com-to-Files.com Remote Server is another explicit connection, authenticated with credentials from the destination site. Review the identity and permissions supplied to the connection. Being the administrator of one site does not by itself authorize an unrelated site, and a credential issued on one site is not a general credential for every site your organization uses.

Subdomain Reuse

A Files.com subdomain is an address assigned to a site, not a permanent identifier of the customer who first used it. Claiming a previously used subdomain does not transfer the former site's files, users, or permissions. Connections to that address can nevertheless reach a different customer's site after the name is reassigned.

A rename without preservation releases the old subdomain immediately. Deleting a preserved subdomain has the same effect. There is no grace period or preference for the previous holder: any Files.com site can claim an available name. Preserving the name keeps it associated with the original site and prevents every site, including the original site, from selecting it as its current subdomain while preservation remains active.

A paid site can also claim a name currently assigned to an expired trial. Files.com automatically changes the expired trial's subdomain and records the change in its Settings Changes log. This allows names held by expired trials to be reused for paid service. It does not apply to an unexpired trial, a paid site's current name, or a preserved subdomain. Names reserved by Files.com are also unavailable.

Preserve an old address while people or integrations still rely on it, and update their destinations before releasing it. A familiar address alone does not establish that it still belongs to the same customer. Custom Subdomain covers rename planning, preservation, and its creation limits.

File Access and Connected Storage

File operations remain subject to the permissions granted to the user or integration. A Remote Server Mount makes connected storage available through Files.com; it does not make every file on that storage available to every user. The connection's access to the remote system and the user's Files.com permissions are separate controls.

The Files.com Agent can perform file operations in your environment. It changes where selected work runs, while Files.com continues to provide authentication, permissions, and administration. The location of an Agent or the authoritative file copy alone does not establish where all file contents travel; that depends on the transfer and processing path.

Files.com's own staff access and confidentiality practices are described in How Files.com Handles Customer Data.