File system layouts affect how each user experiences the folder structure of their Files.com site. The layout determines what a user sees as the top of the file system and how paths are interpreted across every interface, including the Web App, Desktop App, Mobile App, API, CLI, FTP, SFTP, and WebDAV.

Layouts shape presentation. They do not change permissions. The folders a user can actually read from or write to are still governed by folder permissions, whether those are assigned to a user directly, inherited from group memberships, or assigned to the Partner the user belongs to.

If your Files.com deployment includes deep or complex folder hierarchies, file system layouts help you present a cleaner view for each type of user. This reduces confusion by focusing the user's experience only on the folders that matter to them.

File System Layouts Simplify User Experience

In many organizations, files are arranged into operational structures. One common pattern is to give different teams their own folders, grouped by region:

Root Folder
└── Region/
    └── US/
        └── Finance/
        └── HR/
        └── Operations/
    └── EU/
        └── Finance/
        └── HR/
        └── Operations/

Another pattern: an organization with hundreds of customers who provide data that you deliver to vendors might lay out folders like this:

Root Folder
└── Internal/
    └── Finance/
    └──   HR/
    └──   Operations/
└── Customers/
    └──   East/
        └── ACME/
        └── Corpocustomer/
        └── ...
        └── ZedIndustrial/
    └──   West/
        └── BigCorp/
        └── ...
└── Channels/
    └──   AmazingWebMarket/
        └── Vendor1/
        └── Vendor2/
        └── ...
        └── Vendor3/

This may be perfect for internal governance, but overwhelming for someone who only needs one folder.

File system layouts show your users a simplified, relevant file system without restructuring your actual data. Users see only what they need, external partners get a clean experience without internal noise, federated identity users see their corporate drives alongside Files.com content, and administrators retain full control and visibility over the real folder structure.

Available File System Layouts

Each user account has a File System Layout setting that determines how the site's folder hierarchy is presented to the user. There are 5 options (Site Root, Workspace Root, Partner Root, User Root, and Integration-Centric) that offer 3 types of layouts.

Every user belongs to one of 3 containers, and that container determines the user's default layout.

Users on the main site (also known as the Default Workspace) belong to the site itself. Their default layout is Site Root.

Users in any other Workspace belong to that Workspace. Their default layout is Workspace Root.

Users associated with a Partner belong to that Partner. Their default layout is Partner Root, even when the Partner is within a custom Workspace.

Within their default container, a user can be assigned an alternate layout: User Root or Integration-Centric.

The User Root layout narrows the user to a subfolder of their container. The subfolder used for the user's root is supplied through a separate User Root setting. Any user's account can be assigned this user layout, except Site Administrators and Read-only Administrators.

The Integration-Centric layout presents the container alongside their user-specific remote mounts. This layout is intended only for human users who are not Partner Users.

Whichever layout is in effect, the user's ability to read or write any folder under it is still governed by folder permissions and group memberships. A layout shapes the user's view; it does not grant or remove access.

Site Root and Workspace Root

Site Root and Workspace Root offer the same type of default layout. The user's view starts at the top of the container they belong to. For users on the main site (the Default Workspace), that container is the site itself, and the layout is Site Root. For users inside any other Workspace, the container is the Workspace, and the layout is Workspace Root.

Site Root shows the site's root folder as the top-most folder for the user. Each path the user interacts with matches the actual absolute path on the site. This option suits internal users who work across several areas of the site, because paths stay consistent with internal processes and integrations. Site Administrators and Read-only Administrators always use this file system layout.

Workspace Root shows the Workspace's root folder as the top-most folder for the user. Paths the user interacts with are absolute paths within the Workspace boundary. Workspace users cannot navigate outside the Workspace Root regardless of which interface they use.

The layout shows the structure of the container but does not grant access to anything within it. Permissions still determine which folders the user can open and use.

Workspace Administrators can change the File System Layout for users in their Workspace. The available options are Workspace Root (the default), User Root, and Integration-Centric.

Example Site Root Folder View

A user with the Site Root layout sees the Customers/East/ACME/ folder at its absolute path Customers/East/ACME.

Customers
└── East
    └── ACME
        └── inbox
            └── invoice.json

Users with a Site Root layout reference the file as Customers/East/ACME/inbox/invoice.json. A user inside a Workspace with a Workspace Root layout sees the same kind of view, but rooted at the Workspace's root folder instead of the site's root folder.

Site and Read-only Site Administrators Always Use Site Root

Site Administrators and Read-only Site Administrators must use the Site Root layout. The system rejects any attempt to assign any other layout to these users.

Partner Root

Partner Root is the default layout for users associated with a Partner account. The user's / is the Partner's Root Folder, which is shared by every user belonging to that Partner. Partners created inside a Workspace follow the same pattern — their Partner Root exists within the Workspace Root, and Partner users cannot access anything outside the Partner Root, including other folders inside the Workspace.

As with every other layout, Partner Root does not grant access to anything inside the Partner Root. The ability to read or write specific folders is determined by the permissions assigned to the Partner.

Partner users can be assigned User Root to confine them further to a subfolder of the Partner Root. Partner Admins are able to modify their Partner's users' File System Layout and User Root settings.

User Root

The User Root layout narrows a user to a specific subfolder of their container. Anything outside that subfolder is hidden, and the user sees their assigned root folder as the top of the file system. When the User Root layout is assigned, a separate User Root setting chooses which folder is used as the user's root folder. For users with any other layout, the same path is presented in their account as their FTP/SFTP Client Root Folder, where it acts only as an FTP/SFTP jail.

The chosen User Root folder must be within the user's container — within the site root for users on the main site, within the Workspace Root for Workspace users, or within the Partner Root for Partner users. Setting the User Root to the same folder as the container root behaves identically to the default layout for that container.

Choosing a User Root folder does not grant the user access to anything inside it. The user must still be granted folder permissions on the items within their root folder. Permissions on paths outside the User Root are ignored.

User Root reduces distractions and training overhead. "Where do I upload this?" becomes obvious. It suits users who only work in one section of the file system, whether they are internal team members, external collaborators, or Partner users who need only part of the Partner Root.

When a Root Folder Is Moved or Deleted

If a user's root folder is moved or renamed, Files.com updates the user's setting with the new path to their root folder.

When a user's root folder is deleted, the user's setting does not update. The user's root folder now references a folder that does not exist, and they cannot access any files. To fix this, update their root folder setting so that it points at a valid folder.

Example User Root Folder View

Imagine the departmental layout from earlier, expanded at the Region/US/HR folder:

Root Folder
└── Region/
    └── US/
    └── Finance/
    └── HR/
        └── Onboarding/
        └── Policies/
        └── Reviews/
            └── 2025/
            └── 2024/
    └── Operations/
└── EU/
    └── Finance/
    └── HR/
    └── Operations/

For a worker in the US HR department, set their file system layout to User Root and choose the Region/US/HR folder as their root folder. The user then sees the following folder layout:

Root Folder
└── Onboarding/
└── Policies/
└── Reviews/
    └── 2025/
    └── 2024/

The folder the user sees as Reviews/2024 is actually located at Region/US/HR/Reviews/2024.

Integration-Centric

The Integration-Centric layout creates a unified view that combines a user's Files.com content with their personal connections to their company's remote storage.

When Integration-Centric is assigned, the user's / contains a Files.com folder that holds the user's normal container root. For users in the Default Workspace, this is the site root. Users in a Workspace will see the contents of their Workspace root folder under Files.com.

The files listing also shows a separate top-level folder for each Remote Server associated with the user. Each folder is named for the type of Remote Server it represents, such as SharePoint or Google Drive.

The Integration-Centric layout is for users who work across Files.com and their organization's external storage in a single session. It is particularly suited to federated identity scenarios, where users sign in via SSO and automatically see their own Google Drive or SharePoint content mounted alongside the Files.com structure.

Integration-Centric is only available for internal, human (not Shared/Bot) users.

Like every other layout, Integration-Centric does not grant access to your site's folders. The user must still hold permissions on the folders they need to use.

Example Integration-Centric Folder View

A user assigned Integration-Centric who has SharePoint and Google Drive Remote Servers associated with their account sees a structure like this:

/
├── Files.com/
│   ├── marketing/
│   └── engineering/
├── SharePoint/
│   └── Team Documents/
└── Google Drive/
    ├── Shared With Me/
    └── My Drive/

File System Layouts Do Not Grant Permissions

File system layouts shape what a user sees. They do not grant access to anything within that view.

User, Group, and Partner permissions are required for a user to interact with files. Permissions are specified as absolute paths using the actual site root, even when they apply to users with a custom root folder. For users with a User Root, Partner Root, or Integration-Centric layout, permissions on paths outside the user's visible root are ignored. Users cannot reach folders above or outside their assigned root folder, even if a permission would otherwise grant access.

This separation is deliberate. Layout settings change how the file system is presented to a user. Permissions, group memberships, and Partner assignments determine what the user can actually do.

Interactions with Other Features

File system layouts affect every interface where paths matter.

Users use paths relative to their root folder when interacting with all features, including file management, Share Links, Inboxes, Public Hosting, Notifications, SDKs, and client applications.

The exception is that logs record absolute paths.

Logs Record Absolute Paths

Logs and SIEM integrations capture absolute paths because they operate in a system context rather than being tied to a user's perspective. Administrators get a full, consistent historical record.

The exception is API Logs. They capture the paths used in requests and responses, which are relative to the user's root folder.

This dual-layer approach maintains usability for end users and accountability for administrators.

File System Layouts Do Not Apply to Child Sites

Users who have delegated access to a Child Site always experience that site in Site Root layout, regardless of their layout setting for the parent site.