Receiving Files From a Partner System

A supplier, customer, or service provider may already have an application that sends files over SFTP. It needs a hostname, an account, and an agreed upload folder. Your team needs to receive those deliveries without giving the external system access to unrelated files or operating another SFTP server.

Files.com provides the receiving service. A Partner represents the external organization, a Partner Channel establishes its exchange folders and direction, and a dedicated user account identifies the application making the connection. Together, these give the relationship a maintained place in your file environment.

The partner's application initiates each transfer. This is an automated workflow even though receiving the upload does not require a Files.com Automation. Your team configures access and the next stage of processing; the partner owns its sending schedule and application.

Organizing the Relationship

Consider a supplier that sends reports for an internal application to process. Use a Partner for the supplier, with a root folder such as partners/example-supplier. That folder becomes the top of the file tree its Partner Users see. The supplier works with paths inside its own area while your team can organize several relationships under the site's broader folder structure.

A Partner Channel describes a particular exchange within that relationship. A channel named deliveries with direction Files From Partner Only creates an incoming folder and grants the Partner upload and listing access there. It does not grant download access to submitted files. That direction fits a system whose job is to deliver reports, while your internal users receive their own permissions for reading and processing them.

The resulting site path is partners/example-supplier/deliveries/incoming. With the account's Partner Root layout, the partner uses /deliveries/incoming. Providing the partner's view of the path avoids asking its application to use an internal prefix that is already outside its file view.

This example receives files into native Files.com storage. Use the Workspace intended for this relationship; creating a Partner does not require creating a new Workspace. A Site Administrator or Workspace Administrator with authority over that Workspace establishes the folders and accounts.

Establishing the Receiving Area

Create partners/example-supplier in the File Manager, then create Example Supplier under Partners and select that folder as its Root Folder. For a new relationship, begin with a dedicated area so its access is easy to understand.

On the Partner's Channels tab, select Create Partner Channel. Set Folder Path to deliveries, choose Files From Partner Only, and leave the incoming folder named incoming. Saving the channel creates its folders and associated Partner permissions; manually adding the same permissions is unnecessary.

Partner Channel permissions explains the access granted by each direction. Use Files To and From Partner when the supplier also needs to retrieve files your site sends. That direction provides separate folders for submissions and retrieval, keeping the two parts of the exchange clear.

An Identity for the Sending Application

Give the application its own user account assigned to Example Supplier. Use a recognizable username and keep the Partner Root file system layout for the paths above. A separate account lets the team distinguish application deliveries from a person signing in to inspect the relationship.

Set the authentication method to None (Use SSH or API Keys) and enable Shared/bot user. These settings support an unattended account that authenticates with a key and does not need to complete interactive two-factor authentication. People administering the exchange should continue to use their individual accounts.

Enable SFTP in the machine account's allowed protocols and disable the connection methods it does not need. Leave Partner Admin authority off: permission to deliver a report does not require authority to manage the Partner's users.

Ask the partner for the sending application's SSH public key and register it on the account. The corresponding private key stays with the partner's application. Agree on who maintains that key and whom your team can contact when the sending system changes.

Partner Users inherit the Partner's folder permissions. Creating separate usernames identifies separate people or systems; it does not by itself divide the Partner's channels among them. Review the relationship's permissions before adding an account to an existing Partner, especially when it participates in more than one exchange.

What the Partner Needs to Connect

Provide the site's actual connection details and the account's view of the upload path. The partner can keep using its existing SFTP client or application.

Use the hostname rather than a fixed IP address so the client follows the site's connection routing. Complete the client's server host-key verification during setup. SFTP connection settings provides the remaining client settings, including alternative port 3022 when the network blocks port 22.

Agree on the filename convention and what a completed delivery represents. If the partner is sending a daily report, your receiving process needs to distinguish a new report from a corrected or repeated one. Providing an endpoint does not resolve those business rules.

From Arrival to a Usable Report

Have the partner connect with the machine account and upload a nonempty sample with a new filename. As an administrator, open the full site path in the File Manager, download the sample, and check its contents. Review the folder's history to confirm the upload is attributed to the machine account. Then verify a delivery initiated by the partner application itself, using the process that will run unattended.

An administrator's upload would verify neither the partner's credentials nor its application configuration. Testing the real sender establishes that the account, path, protocol, and publication process work together.

Arrival makes the report available in the intake folder. Your team still decides what happens next: an application may retrieve it, staff may review it, or a Files.com Automation may deliver it onward. Confirm that receiving process with a representative report; a successful SFTP upload does not establish that its data was accepted.

For scheduled deliveries, an Expectation can detect that an expected file did not arrive by its deadline. Assign an internal owner who can use the delivery history, contact the partner, and distinguish a missed submission from a failure after receipt. The channel gives the exchange a location and permissions; those operating arrangements make it a dependable input to the business process.