Trading Partner Onboarding
Onboarding a supplier's nightly invoice feed in Files.com means agreeing on more than how to connect. Accounting needs complete files it can import, and both businesses need a way to handle missing, rejected, or repeated deliveries. The onboarding agreement brings those requirements together so the exchange can keep running when people, systems, or circumstances change.
A trading partner is the other organization participating in the exchange. That business relationship exists regardless of whether you model it with a Files.com Partner, a Remote Server, an AS2 trading partner, or another supported arrangement. Partner File Exchange explains the Files.com resource choices.
Connection Choice
Our connection recommendations provide the starting point when you can propose the method. With Connected Sites, the Host Partner shares folders with agreed permissions, and the Guest site's Site Administrator approves access. Files.com handles the connection without requiring the businesses to exchange partner login credentials or protocol keys.
If the partner uses another system and requires a particular method, the agreement needs to reflect that requirement. Record whether the partner connects to Files.com or Files.com connects to its server, along with who controls the schedule.
The connection choice determines how much setup the agreement needs to cover. Every exchange needs agreed access, data, schedules, and processing outcomes. An external SFTP or AS2 connection adds its own identities and credentials; those requirements need not become an onboarding exercise for a partner using Connected Sites.
The Exchange Record
A shared connection and data agreement records the business requirements behind your Files.com configuration for each environment. The subjects below help identify what to settle before testing. Only the rows relevant to the chosen method need to be included.
| Subject | Information to agree and record |
|---|---|
| Purpose and ownership | Business process, producing and consuming systems, responsible organizations, and the outcome that counts as success |
| Direction | Who opens each connection, who sends each file, and who schedules pickup or delivery |
| Endpoint | Protocol, hostname, port, paths as seen by the actual account, and any separate callback URL |
| Connection profile | Required TLS or SSH compatibility; explicit or implicit FTPS; FTP data mode and passive range where applicable |
| Account | Username or service identity, required authentication method, credential owner, and permitted file operations |
| Server trust | Expected SSH host-key algorithm and fingerprint, or TLS hostname and certificate trust requirements, including any pin |
| Network rules | Destination hosts and ports, all possible public source addresses or ranges, failover paths, and the operator maintaining each allowlist |
| File encryption and signing | Required PGP profile, recipient public key, sender verification key, full fingerprints, signature form, and armor or compression choices |
| AS2 profile | Sender and receiver AS2 identities, endpoint URLs, public message certificates, signing and encryption requirements, receipt mode, and MIC/signature expectations |
| Data format | Encoding, separators, schema or EDI standard and version, implementation guide, and content validation requirements |
| File and batch identity | Naming convention, business or delivery IDs, revision rules, duplicate detection, and overwrite behavior |
| Completion | Temporary/final names, staging and ready locations, done files, or manifest rules that make input eligible |
| Timing | Source availability, schedule, time zone, business calendar, deadline, and permitted lateness |
| Acknowledgment | Transfer, message, and business results required; return method, correlation identity, timeout, and rejection response |
| Recovery and retention | Retry ownership, uncertain-delivery reconciliation, retained input and evidence, cleanup, and manual recovery authority |
| Contacts and changes | Technical, network, credential, and application contacts; escalation route; notice and approval process for changes |
Record public keys, certificates, and approved fingerprints with their purpose and environment. Exchange passwords, API secrets, private keys needed by an authorized service, and passphrases through the appropriate secure credential process. Keep their owners and configured use in the shared agreement, and keep the secrets themselves in the authorized credential store.
Test and Production
Test and production need agreed values on both sides, including the relevant hostnames, accounts, folders, keys, AS2 identities, schedules, and acknowledgment destinations. An environment labeled “test” on your side can still connect to a production endpoint at the partner, so isolation depends on the actual configuration.
Test data should be recognizable to the receiving system and safe for it to process, without creating a real order, invoice, or payment. Both teams also need to know whether a test stops at transport or reaches the application's business checks, since those results establish different things.
Exercise the same consequential behavior in both environments, with separate identities and destinations where required. If production uses a different network route or certificate trust store, test that difference before relying on the earlier result.
Within Files.com, Workspaces and Child Sites provide different isolation and configuration boundaries. Choose the one appropriate to what you are testing, then confirm the external endpoints independently.
A Representative Acceptance Test
A representative test uses the kind of client, service account, and network that will run the production job, with agreed test destinations. Once server identity and authentication have been checked, exercise the file operations the job requires. These may include listing, uploading, downloading, and, where the design calls for them, replacement or deletion.
Follow one delivery through the entire process, from its completion signal through any decryption, signature verification, validation, and onward transfer. Include the application's acceptance and acknowledgment back to the sender. Correlation identifiers connect the records so both teams can trace that same delivery across the handoffs.
Then exercise the failure cases the business must handle: an interrupted upload, missing file, duplicate, correction, invalid data, unavailable destination, and missing acknowledgment. A test is useful when the operators can explain the observed outcome and recover it using the agreed procedure.
For AS2, validate the required receipt, signature, and MIC rather than stopping at an HTTP status. For other protocols, confirm the response-file, callback, log, or application-status arrangement that tells the partner its delivery reached the agreed stage.
Production Handoff
Each team needs to know which failures it owns. Missing source exports belong with the producer, reachability and transfer failures with the connection operator, and unusable records with the mapping or application owner. The agreement also needs a team to coordinate with the partner when a problem spans those responsibilities.
Delivery windows and alerts need a shared time zone and calendar, including whether times stay fixed in UTC or follow local daylight-saving changes. Work back from the completion deadline to allow time for transfer, processing, acknowledgments, and recovery. A scheduled start alone says nothing about when the job must finish.
Use Production Validation & Change Control for the Files.com deployment handoff. Keep recoverable input until the agreed result is recorded and the retention policy permits cleanup.
Changes After Onboarding
Treat a changed hostname, source address, protocol profile, account, key, certificate, document format, or schedule as a coordinated exchange change. Identify who announces it, which environments and partners are affected, how it is verified, and when the previous configuration is retired.
The effects depend on what changes. A key or certificate replacement can require updated trust, while a network change can depend on the other side updating its allowlists. Moving an endpoint can require a new hostname check or host-key entry. A new document version can leave the connection untouched but require new mapping and acknowledgment tests.
Keep the exchange record current with the configuration both parties actually use. A contact list and an agreed change process make the next renewal or rejected delivery a team responsibility rather than knowledge held by the person who performed the original setup.