A Partner represents an external organization that works with your site, such as a client, vendor, agency, or supplier. Each Partner is an isolated, secure container for that organization's users and automated accounts. Everything those users do is confined to the Partner's assigned root folder, so each partner can only see and manage its own data. Think of each Partner as a guest suite within your site, with its own front door, its own set of keys, and no view of anything beyond its walls.

You could give an external organization access with ordinary user accounts and folder permissions. Partners add what that approach can't. Partners stay strictly isolated from each other, administration can be delegated through Partner Admins, and each partner can be managed as a single unit, from onboarding through offboarding. If you're not sure Partners are the right fit, Comparing Partners to Related Features explains and compares the alternatives.

What You Can Do With Partners

Here are some examples of how Partners can be used.

Exchange Files With Many Partners Without Any of Them Seeing Each Other

Exchange EDI files with dozens of vendors, each confined to its own root folder. No vendor can see another vendor's files, folders, or users, and no vendor can tell that other vendors exist. Because each Partner has a single set of permissions covering all of its users, onboarding another vendor doesn't mean rebuilding permissions user by user.

Let Each Partner Manage Its Own Users and Credentials

Designate Partner Admins within each Partner and let them add and remove their own users, reset passwords, and manage SSH keys, within limits you set. When someone joins or leaves, the partner handles it. Your Site Administrators stop provisioning individual external accounts and fielding password resets.

Offboard a Partner Cleanly When the Relationship Ends

Deleting a Partner deletes all of its user accounts, and the Partner's IP Whitelist entries are removed with it. For ongoing hygiene, Tags let User Lifecycle Rules automatically disable and delete inactive users in matching Partners.

How Partners Work

Partners are designed around four concepts.

A Partner is the container for one external organization, holding its users, permissions, and settings, with an optional Responsible Party naming the internal owner of the relationship.

The Root Folder is the boundary of the Partner's access. The Partner's users see it as the top level of your site no matter how they connect, and they cannot access any path outside it.

Partner Channels create structured two-way exchange paths under the root folder, with folders and permissions applied automatically.

Partner Users are the external accounts themselves, including Partner Admins, who can be delegated user management for their own Partner.

Partners and Workspaces

Every Partner belongs to a Workspace. On sites that use only the Default Workspace, all Partners are part of that Workspace. When Custom Workspaces are in use, each Partner belongs to the Workspace where it was created and is managed by that Workspace's Administrators.

This model lets each team or business unit manage its own external relationships independently. A Workspace Administrator has the same Partner management capabilities as a Site Administrator, scoped to their Workspace. They can create Partners, configure root folders and permissions, manage Partner Admins and their settings, and onboard and offboard Partner users. Workspace Administrators cannot manage Partners in other Workspaces.

Partner users within a Workspace are confined to the Partner's root folder, which must sit within the Workspace root. They cannot access folders in other Workspaces or on the main site.

Partners overlap with several other Files.com features for granting and organizing access. The comparisons below explain what each alternative does and when to choose it over a Partner.

Partners vs. Users With Folder Permissions

A regular user with folder permissions can be given the same folder access as a Partner. The difference is everything around that access. Partner Users are locked to the Partner's root folder and see it as the top of the site, permissions are granted once to the Partner and inherited by every user in it, user management can be delegated to the partner itself, and deleting the Partner removes all of its accounts at once.

For a single external individual, a user account with folder permissions is enough. For an organization with multiple people or automated systems, use a Partner, so the organization is one thing to manage instead of a set of accounts that drift apart.

Partners vs. Groups

Groups share permissions among your internal users. Group members can belong to multiple groups, carry their own individual permissions, and see whatever the sum of those grants allows.

Partners enforce the opposite. A user belongs to exactly one Partner, cannot be added to a Group, and receives only the permissions granted to the Partner. Use Groups to broaden access for internal users. Use Partners to constrain access for external organizations.

Partners vs. Workspaces

Workspaces separate internal teams or business units, each with its own administrators, users, and folder tree. Partners separate external organizations from your site and from each other.

The two work together rather than compete. Every Partner belongs to a Workspace, so each internal team can manage its own set of external relationships. Use Workspaces to divide your own organization. Use Partners to bring outside organizations in.