Accessing Workspaces

How a user accesses a Workspace depends on their account, permissions, and how they connect. Site Administrators and Default Workspace users with cross-workspace access use a Workspace switcher to move between Workspaces. Cross-workspace access can be assigned directly or inherited through a Group, including Workspace Administrator access.

Users whose accounts belong to a Custom Workspace see only that Workspace when they connect. Partner users belong to a Partner organization within a Workspace and see only the folders shared with them through that Partner relationship.

Each interface handles Workspace context differently, as described below. See Workspaces for an overview of what Workspaces are.

Workspace Switcher

A Workspace switcher appears in the Web App, Desktop App, Mobile App, and CLI when the logged-in user has access to more than one Workspace. It is hidden when the user has access to only one Workspace.

Users with access to multiple Workspaces include:

• Site Administrators, who have access to all Workspaces on the site.
• Default Workspace users who have been given access to one or more Custom Workspaces by a Site Administrator. See Workspace Access and Administration for how workspace access is assigned.
• Workspace Administrators who have been designated as an administrator for more than one Workspace.

When a user switches into a Custom Workspace, the Workspace name is shown in the header as a visual indicator that they are no longer in the Default Workspace.

Default Workspace Setting

A user with access to multiple Workspaces can choose their default Workspace for login. On the next login, the platform routes them to that Workspace instead of the site default.

This setting is useful for users who work primarily in a non-default Workspace and would otherwise navigate away from the default at the start of every session. Users with access to only one Workspace see no change.

The setting is on the My Account page, in the workspace picker. The user chooses Set as Default for one of their accessible Workspaces.

Site Administrators can set or change the Default Workspace setting on a user's record. This setting appears when editing a user's profile. Standard users and Workspace Administrators cannot change another user's Default Workspace setting.

If a user loses access to their configured default Workspace, or that Workspace is deleted, the setting clears automatically. The platform then routes the user to the site default. When a login carries an explicit destination URL for a specific Workspace, that destination takes precedence over the setting.

Web Interface

Site Administrators and users with access to multiple Workspaces use the Workspace switcher in the Web Interface to switch between Workspaces. Users who belong to a single Custom Workspace see only that Workspace when they log in and do not see a switcher.

Desktop App

The Desktop App includes a workspace picker for users with access to more than one Workspace.

Mobile App

The Mobile App for iOS and Android includes a Workspace switcher for users who have access to more than one Workspace. When the user is inside a Custom Workspace, the Workspace name is shown in the header with a visual indicator. Tapping the indicator opens a Workspace selection modal. The switcher mirrors the Web App behavior.

API

An API client can select a Workspace to scope its requests to that Workspace's resources. Site Administrators can select any Workspace on the site; Default Workspace users can select Custom Workspaces they have access to directly or through a Group. Selecting a Workspace does not grant access to it.

With an API key, selecting another Workspace requires a Full Access key created in the Default Workspace, and the requested Workspace must be within the key's account access. Files Only keys and keys created in a Custom Workspace remain in their creation Workspace. Workspace Scoping explains which key to use.

Workspace Administrators whose accounts belong to a Custom Workspace authenticate normally, with API access automatically scoped to that Workspace.

The developer Workspace guide covers request scoping, permission assignment, and SDK examples.

CLI

Workspace selection requires CLI version 2.15.313 or later.

The Files.com CLI supports Workspace selection in two ways.

Pass --workspace-id <ID> to scope a single command to that Workspace. To set a Workspace for subsequent commands, run files-cli config set --workspace-id <ID>. Set the ID to 0 to select the Default Workspace. The CLI Workspace guide covers configuration and permission assignment.

To clear the saved selection, run files-cli config reset --workspace-id. With no selection, the CLI uses the account's normal API access without adding an explicit Workspace scope. API keys confined to a Workspace remain within it.

Both options are available to Site Administrators and to Default Workspace users who have been given access to a Custom Workspace.

SDKs

Every Files.com SDK supports scoping calls to a specific Workspace. The developer Workspace guide explains the shared access model and offers language-specific SDK examples.

Terraform

Workspaces can be provisioned, updated, and managed through the Files.com Terraform provider. This supports infrastructure-as-code workflows where Workspaces are managed alongside other site resources.

File Transfer Protocols

Users who belong to a Workspace access their Workspace files through FTP, SFTP, and WebDAV. The Workspace boundary constrains the visible file system to the Workspace root.