Partner Channels
A Partner Channel creates a structured exchange path under a Partner's root folder for delivering files to the partner, receiving files from the partner, or both. Files.com creates the exchange folders in the layout you choose and applies their permissions automatically.
Use a one-way Channel when an exchange only delivers or collects files. A delivery-only Channel has no upload folder for the partner to leave files in, so it does not create an unmonitored place for submissions. Use a two-way Channel when both sides need to send files.
A Partner can have more than one channel. A partner channel can also enforce a required folder structure inside the exchange through Managed Folders, and one configuration can be applied across many Partners with Partner Channel Templates.
Partner Channels vs. Manual Folder Setup
Building the same exchange by hand means creating the chosen folder layout and the corresponding permissions under each Partner's root. You must then keep that structure and access consistent every time the exchange changes. A Partner Channel creates the structure in one step and applies permissions automatically. Templates keep the configuration consistent across Partners.
Partner Channel Folders and Directions
A Partner Channel always has a base folder. Its Direction determines whether the partner downloads files, uploads files, or does both. By default, Files.com creates a subfolder beneath the base folder for each enabled direction. A one-way Channel can instead use the base folder directly.
| Direction | Subfolders in the Default Layout | Exchange |
|---|---|---|
| Files To and From Partner (default) | To Partner and From Partner | Your site and the partner send files to each other |
| Files To Partner Only | To Partner | Your site delivers files for the partner to download |
| Files From Partner Only | From Partner | The partner uploads files for your site to collect |
A disabled direction has no folder, permissions, Route Path, or Managed Folder Paths. When folders already exist at the enabled paths, the Channel adopts them as its own folders, as long as the existing structure matches its configuration. Files.com never deletes existing content to make a Channel fit, so creating the Channel fails with a detailed error message when something is in the way, such as a file sitting at a configured folder path.
The two directions are named for the flow of files between your site and the partner:
- The To Partner Folder holds files your site delivers for the partner to retrieve. With directional subfolders, its default name is
outgoing. - The From Partner Folder holds files the partner submits to your site. With directional subfolders, its default name is
incoming.
A channel's Folder Path is a relative path. It gives the partner channel's location beneath the Partner's root folder, such as EDI, and is the path the partner sees. The Channel Folder Path is the corresponding absolute path on your site, such as partners/Acme Co/EDI, which administrators see in the partner channel's settings.
A Folder Path is not limited to a single level. You can place channels at multi-level paths, such as EDI/X12/Orders and EDI/EDIFACT/Orders.
Each enabled direction can carry a required substructure through Managed Folders, or resolve to a different location through a Route Path. Those settings apply to the directional subfolder or to the Channel folder itself, according to the layout.
The Channel's base folder, To Partner and From Partner folders, and Managed Folders are native Files.com folders. They cannot be Remote Server Mounts or sit inside one. This keeps the Channel's routing and folder-creation rules in control of the exchange. A Route Path lets the exchanged files stay on a Remote Server while the Channel folders remain native.
Channel Folder Layout
Choose Use a directional subfolder when you want separate outgoing and incoming folders, or a one-way exchange that can later gain a second direction. This is the default layout and is required for two-way Channels. Leaving a directional folder name blank uses its default name; it does not remove the subfolder.
Choose Use the channel folder directly for a one-way exchange when the Channel path itself needs to receive or deliver files. For example, a delivery-only Channel with the Folder Path DailyFlows presents a file as /DailyFlows/report.csv, without an outgoing level.
This preserves a path already used by a partner's script, so the partner does not need to change that path as part of moving the exchange to Files.com. The same layout supports collection-only Channels, with uploads going directly into the Channel folder.
The layout is selected at creation and cannot be changed afterward. Existing Channels keep their layout, and changing or reassigning a Template cannot convert it.
On a one-way Channel's edit form, Folder Layout is a read-only value with a note explaining that it is fixed at creation. A Channel that uses its folder directly also has a read-only Direction and stays one-way; choose directional subfolders at creation if the same Channel will need both directions.
An Example EDI Exchange
Suppose Acme Co is a Partner whose root folder is partners/Acme Co, and you create a partner channel with the Folder Path EDI and the default Files To and From Partner direction. Files.com creates partners/Acme Co/EDI with outgoing and incoming folders inside it, and grants Acme's users their access to all three in the same step.
You (or an Automation) place files in outgoing, and Acme's users download them. Acme's users upload their files into incoming, and your team or automations pick them up from there. Onboarding the next partner is the same single configuration again, and its channel folders and permissions come out identical to Acme's.
What the Partner Sees
A Partner User who connects through the web interface, SFTP, or any other protocol sees the Partner's root folder as the top level of the site. In the example above, an Acme user browsing the folder tree sees EDI at the top, with outgoing and incoming inside it.
They can browse and download from outgoing, and upload into incoming. They see nothing of your wider site, other partners, or the partners/Acme Co prefix that administrators see.
For a Partner whose users mostly upload files through the web interface, you can enable the Partner Channel Home Page. It shows one upload destination for each folder those users upload into, and replaces the File Manager as the first page they see after signing in.
Partner Channel Permissions
A Partner Channel sets its permissions automatically. With directional subfolders, Partner Users and a connected Guest site receive access to the base folder and only the enabled directional folders:
| Folder | Permission | What the Partner Can Do |
|---|---|---|
Base folder (EDI in the example) | List Only, non-recursive | See the enabled directional folders |
To Partner Folder (outgoing by default) | Read Only, recursive | Browse and download the files you deliver |
From Partner Folder (incoming by default) | Write Only and List Only, recursive | Upload files and see what has been submitted, without being able to download anything back out |
When a one-way Channel uses its folder directly, that folder receives the enabled direction's recursive permissions. A delivery-only Channel is Read Only; a collection-only Channel is Write Only and List Only. Managed Folder restrictions still control where files can be placed.
In a Connected Sites relationship, Channels are configured on the Host Partner. Guest Site Administrators access them under _/Sites/<host-site-id> on their own site, with the same Route Path behavior and Managed Folder restrictions as Partner Users. A Partner with the Guest role has no local Channels of its own.
These permissions are inferred rather than created as editable permissions. Folder Permissions shows the Partner Channel context for these folders and keeps the inferred permissions out of the editable permissions table, so the partner channel's access model stays intact and cannot be partially edited into an inconsistent state.
A Partner Channel's permissions are independent of any other folder permissions the Partner has been granted. The partner channel grants access only to its own folders, and it neither extends nor is changed by other access permissions that the Partner has been granted. A Partner Channel can be set up only within the Partner's own area.
Non-Partner users can be given access to the partner channel's folders through ordinary folder permissions. Those permissions are entirely separate from the partner channel's inferred permissions. Granting a non-Partner user access to a partner channel folder does not change what the partner can do, and the partner channel's permissions do not affect the non-Partner user's access.
Managed Folders
Many exchanges depend on a folder structure inside the exchange folders, not just the folders themselves. Monthly reports land in outgoing/reports/monthly, appeals go to outgoing/appeals, and receipts arrive in incoming/receipts.
When those subfolders are created and managed by hand, the structure drifts. A partner renames a folder, a file lands one level too high, and the automation that reads from the expected path stops finding its files.
Managed Folders make that structure part of the partner channel. Each enabled direction's Managed Folder Paths setting lists the required folder paths inside that direction's folder, such as reports/monthly under outgoing. Files.com creates the full hierarchy when the partner channel is created and enforces it afterward.
When the Channel uses its folder directly, Managed Folder Paths start at that folder. A collection-only Channel at Submissions with the Managed Folder Path claims/received accepts files at /Submissions/claims/received, without an incoming level.
A Managed Folder cannot be deleted, renamed, or moved, so the paths both sides depend on are always there. At levels that carry configured subfolders, users cannot create files or unconfigured sibling folders, which keeps stray content out of the structure your automations rely on. Inside the deepest Managed Folder of each path, work continues as normal, and files are uploaded and downloaded there as in any partner channel folder.
Creating the partner channel fails with a detailed error message when the structure cannot be applied cleanly. A file sitting at a configured path, a folder already managed by another partner channel, or stray content at a managed level each blocks creation. Files.com never deletes customer content to make the structure fit.
Adding Managed Folders to Existing Folders
You can bring existing folder structures under management. Make the structure match first, then add the Managed Folder Paths.
Bring the Partner's existing folders in line with the paths you plan to configure. Clear stray files and unconfigured folders out of every level that will carry configured subfolders, because Files.com will not delete them for you and they block the partner channel while they are present.
Remove any folder permissions and Lock Subfolders folder settings you created to protect the structure by hand, since they also block the partner channel, and the partner channel enforces the structure on its own from here forward. Then add the Managed Folder Paths, and Files.com adopts the matching folders and enforces the structure from that point on.
If a script has been recreating or managing these folders for you, retire it once the partner channel takes over.
Route Paths
Use a Route Path when the files a partner exchanges need to land where an existing system already reads or writes them, instead of an ordinary folder under the Partner's root. That existing system might watch a folder on a Remote Server Mount or a native folder tied to an internal workflow.
The target stays on the same site and within the Channel's Workspace. The partner keeps working in the channel path while your operations resolve to the real location, so no separate step is needed to move files between the two.
The To Partner Route Path and From Partner Route Path settings point the partner channel's To Partner or From Partner folder at the target folder, so the two locations show the same files. With the direct layout, that folder is the Channel folder itself.
Anything in the target folder appears in the partner channel folder, and anything placed in the partner channel folder appears in the target, subject to the direction's permissions. Listings, recursive listings, ZIP downloads, file counts, and folder sizes all reflect the target's accessible content. Routing is configured on the partner channel itself, and no separate Automation or copy of the files is required for it.
For files stored on a Remote Server, set up a mount on a separate folder and set the Channel's Route Path to that folder or a folder within it. The partner continues to use the Channel path, and file operations reach the remote storage through the route.
For example, your reporting system writes report.csv into shared/daily-flows. A delivery-only Channel at DailyFlows, using the Channel folder directly and the To Partner Route Path shared/daily-flows, lets the partner download the file at /DailyFlows/report.csv. The reporting system keeps writing to its existing folder while the partner keeps reading its existing path.
A Partner Channel and its Route Path targets must belong to the same Workspace. This applies to the Default Workspace as well as Custom Workspaces.
Routing connects the Channel to an existing location without expanding the Partner's Workspace access. Files.com validates that the target is within that Workspace, exists, and is accessible when you create the Partner Channel. Linking to a folder on a Remote Server, for example, requires that the Remote Server is online and that the folder exists there.
Route Paths cannot target a Child Site or Connected Site under _/Sites/. Files.com rejects such a path when a Channel is saved. Template route path patterns have the same restriction.
Access through a route is authorized at the Channel path the person or process requests. It does not require a separate permission grant on the target path. The Channel's directional permissions and Managed Folder rules continue to control the exchange. Routing to a Remote Server Mount also remains subject to the remote connection's permissions.
Several Channels can route to the same target folder. Use this for content all of those Partners should share, such as a common report feed.
Each Channel presents the same target content under its own directional permissions: delivery Channels allow browsing and downloading, while collection Channels allow listing and uploading without downloading. A submission through a collection Channel appears in the other Channels routed to that destination; Partners with a delivery Channel to it can also download the submission.
Choose separate target folders when each Partner's files or file listings need to remain separate. Templates can use either a fixed shared target or a Partner-specific pattern.
A Route Path and Managed Folder Paths can be used together on the same direction. When they are, the routed destination must be empty or already match the configured structure at every level that carries a configured subfolder.
Each Channel retains ownership of the folders it presents under its Partner's root. Managed Folders also belong to one Channel: sharing a route does not let several Channels manage the same target subfolders. Use separate destinations when several Channels need to enforce the same Managed Folder Paths.
Folder Settings on Routes
A routed folder uses the Folder Settings of its target, including rules inherited by that target. If the target is itself routed, settings come from the final folder.
File-processing and retention settings on the Channel path or above it do not carry to the routed content. For example, a GPG rule on the target intake folder processes files arriving through every Channel routed there; a GPG rule above one Channel's path does not give that Channel different processing.
Routes sharing a target share its settings. Choose separate targets when the exchanges need different processing or retention.
At the route path, you see the target's settings and Metadata Category under the usual Folder Settings visibility rules. While a route is configured, you cannot add new Folder Settings to its Channel exchange folder. Settings already there remain configured but do not govern routed content.
Configure settings on the target instead; settings configured on subfolders reached through the route belong to the corresponding target subfolders.
Lock settings on the Channel path and its ancestor folders apply alongside locks at the target. Activity notifications instead match the recorded operation and path, as described below.
When Archive Removed Files applies at the target, a routed deletion or replacement preserves the old file in that rule's archive folder, using the file's path relative to the folder with the rule. The Channel path does not become an extra prefix in the archive. Access Across Sites and Storage explains settings and activity across combined connections.
Activity and Workflows on Routes
A Route Path lets a partner keep using its exchange folder while your systems use the target folder. Recording native upload and copy arrivals at the target lets one intake workflow handle submissions from every Channel routed there. Other operations can use the Channel path in History. The operation and upload mode determine which path is recorded.
| Operation Through the Channel | Recorded Path |
|---|---|
| New or replacement upload to native storage on the same Site | The target file's resulting path |
| Native file copy into the target | The target file's resulting path for the destination record |
| Buffered upload into a Remote Server Mount target | The target path in the mount, when Files.com receives the upload, before onward delivery |
| Read, folder creation, delete, move, or append upload | The requested Channel path |
| Unbuffered upload into a Remote Server Mount target | The requested Channel path |
For example, a Channel at /partners/acme/incoming routes to /intake/orders. A native upload through /partners/acme/incoming/report.csv records its arrival at /intake/orders/report.csv. A later download through the Channel records /partners/acme/incoming/report.csv.
Email notifications, notification Folder Settings such as Webhooks, file activity events in Event Channels, and file-triggered Automations use the recorded activity, subject to their own action and path filters. A rule limited to the Channel path or its ancestors cannot respond to an arrival recorded outside that scope.
Configure responses to native uploads and copies at the target folder, or at an ancestor whose scope includes it. Select the actions the workflow needs, including replacement uploads or copies when appropriate. In the example, an upload notification covering /intake/orders can respond; one limited to /partners/acme/incoming cannot respond to that target-path event.
Several Channels sharing a target share those destination-based arrivals and responses. The target path alone does not identify which Channel was used. Choose separate target folders when exchanges need distinct arrival processing or when the destination path must identify the exchange.
Creating a Partner Channel
Site Administrators and Workspace Administrators manage Partner Channels. Workspace Administrators manage only Partners within their own Workspace.
Set the Channel's Folder Path and Direction on the Partner Channel form. For a one-way exchange, Folder Layout offers Use a directional subfolder or Use the channel folder directly. The form previews the resulting exchange path relative to the Partner's root folder.
For a delivery-only Channel at DailyFlows, the preview shows /DailyFlows/outgoing with the default subfolder or /DailyFlows with the direct layout, so you can compare it with the path the partner's integration expects. Configure the Files To Partner and Files From Partner sections for the directions you enable. Each enabled direction can optionally use a Route Path.
Choosing a one-way direction hides the other direction's fields and clears any values already entered in them. With directional subfolders, you can override the default names using the To Partner Folder Name and From Partner Folder Name settings. Choosing Use the channel folder directly clears both folder-name overrides: the Folder Path already names the exchange folder.
The Partner Channels table offers Direction and Folder Layout columns. Folder Layout shows Channel folder or Directional subfolders, so you can distinguish Channels that use their folder directly from those with subfolders.
On a one-way Channel, the disabled direction's folder name, folder path, and route path columns display None. When the Channel uses its folder directly, the enabled direction's folder-name column shows Channel folder, and its folder path is the Channel Folder Path.
A Remote Server Mount at or above any configured Channel folder blocks creation. Choose a native location for the Channel and use a Route Path to reach remote files. Files.com also rejects a change to the Partner's root folder if it would place existing Channels on or inside a mount.
API Direction Values
The Partner Channels API accepts an optional direction field: two_way for Files To and From Partner, to_partner for Files To Partner Only, or from_partner for Files From Partner Only. Omitting the field when creating a Channel defaults to two_way.
The API also accepts and returns the boolean use_channel_root, which defaults to false for directional subfolders. Set it to true at creation to use the Channel folder directly, with direction set to to_partner or from_partner and both folder-name overrides blank. The value cannot change after creation.
Configuration for a disabled direction must be blank, including its folder name, Route Path, and Managed Folder Paths. The API enforces the same direction-change rules as the form: only a Channel with directional subfolders can expand to two-way, and changes from two-way to one-way or between the two one-way directions are rejected.
Expanding a One-Way Channel
You can expand a one-way Channel that uses directional subfolders by changing its Direction to Files To and From Partner. Configure the newly enabled direction's folder name, Route Path, and Managed Folder Paths as needed.
Saving creates the missing directional folder and applies the Partner's permissions to it, just as when creating a two-way Channel. A Channel that uses its folder directly cannot gain a second direction.
For the directional-subfolder layout, the only direction change after creation is from one-way to two-way. A Channel cannot change from two-way to one-way or switch from one one-way direction to the other, because those changes would require removing existing folder structure and handling its data.
The edit form for a one-way Channel with directional subfolders offers its current direction and Files To and From Partner. A two-way Channel shows Direction as a read-only value, with a note that neither direction can be removed.
For a Channel created by a Template, change the Template's direction to expand its assigned Channels together.
Moving and Renaming Folders
The Channel folder and its directional folders cannot be deleted, moved, or renamed while the Channel is active, whether or not they are routed. Every folder above the Channel also remains protected from moves and renames.
This applies to Site Administrators and users with Full permission, even when no Managed Folders are configured. It keeps the Channel's configured paths and inferred permissions aligned with the exchange folders.
For example, a Channel at exchanges/Claims beneath a Partner's root folder prevents moving or renaming both exchanges/Claims and exchanges, as well as the Partner's root folder and its ancestors.
Deleting the Channel removes this restriction for that Channel. A folder remains protected while any other active Channel is at or beneath it. For a Template-owned Channel, remove the Template assignment before deleting the Channel.
Moving or Deleting a Route Target
A Route Path does not by itself protect its target folder from being moved, renamed, or deleted. Moving or deleting the target directly still requires the usual folder permissions and must satisfy its locks and other restrictions.
When you move or rename a target folder, or a folder above it, through Files.com within the Channel's Workspace, an individually configured Channel's Route Path updates to the new location. For example, moving /intake/orders to /operations/orders updates a route that pointed to /intake/orders. Partners keep using their existing Channel paths. On native storage, this is part of the background path update, so verify the moved contents are available before dependent work uses them.
Template-managed Channels keep the paths set by their Template when a target or its parent moves. Change the Template's route path pattern to use the new location. This keeps assigned Channels under the shared configuration instead of changing one independently. A move to another Workspace also does not move the Channel with it; review the Workspace move rules when planning that change.
A route uses whichever folder is currently at its configured path. Deleting the target leaves the route configured, but file operations through it fail while the target folder is missing. If a folder is later created at the same path, the Channel reaches that folder's content under its existing directional permissions. The same applies to a Template-managed route left at an old path after a move. To end access through a route deliberately, change or remove its routing configuration, or delete the Channel.
Deleting a Partner Channel
Deleting a partner channel ends Managed Folder enforcement, stops Route Paths from resolving, and removes the inferred permissions. The folders and their files stay intact, so deleting a partner channel never causes data loss.
For a routed Channel, the files remain at the route destination. Deleting one Channel does not delete those files or remove other Channels' routes to the same destination.
When the exchange data itself is no longer needed, delete the remaining folders and files manually. Confirm first that nothing still depends on the data, because that manual deletion is the only step in the process that removes any files.