Connect Freight Files to Your Salesforce Workflows
Route structured freight files from ERP, WMS, and carrier systems into FTM through configured file-transfer channels, eliminating manual data handoffs between platforms.
File Transfer Pipeline / Illustrative
The Challenge
Files that arrive but never connect
ERP, WMS, and carrier platforms generate freight files as a natural part of operations: shipment orders, dispatch confirmations, invoices, and status updates. The problem is not producing those files. It is getting them into Salesforce in a structured way without routing every one through a manual entry step.
Without a defined file-transfer path, export files sit in shared drives and email inboxes. Data that belongs in a Salesforce Load record accumulates outside the platform where it would be useful.
Operations teams download files from partner portals or FTP servers, then copy field values into Salesforce by hand. The same data travels from one system to another through a person rather than a configured channel.
Different senders use different file locations, naming conventions, and delivery cadences. Without a defined integration, every new file source requires a separate manual process rather than fitting a shared pattern.
Partner systems export dates, codes, and reference numbers in formats that do not match Salesforce field expectations. Reconciling those differences manually before entry adds time and creates opportunities for error.
Integration Pattern
How freight file transfer connects to FTM
FTP file transfer integration provides a structured path from a source system to a Salesforce Load record. The protocol, directory structure, timing, and exception-handling behavior are agreed and configured during implementation.
File deposited by source system
An ERP, WMS, or carrier platform exports a structured file and places it in the agreed transfer directory. The file format and naming convention are defined during integration design.File retrieved via the configured channel
The integration retrieves the file using the transfer protocol and credentials agreed during implementation. How often retrieval occurs and how it is triggered are part of the integration configuration.Format and structure verified
The file is checked against the expected format before processing begins. Structural errors or unexpected content trigger exception handling rather than a partial or incorrect record write.Fields mapped to Salesforce
Configured mapping rules translate file fields to the corresponding Salesforce fields in FTM. Transformation rules such as date format conversion or code normalization are part of the mapping configuration.Salesforce record written
Mapped data is applied to the appropriate FTM objects. How new and existing records are handled (whether a matching Load is updated or a new record created) is configured per the agreed integration scope.
Transfer Methods
FTP, FTPS, and SFTP: what each one is
These three protocols each describe a different approach to file transfer. They are transport mechanisms, not data formats. Which one is appropriate for a given integration depends on the source system, the security requirements, and the transfer environment.
FTP transmits credentials and file contents in plaintext. Consider it only for controlled internal networks where protocol-level encryption is not required and network-level controls are already in place. It is generally not appropriate for sensitive data over shared or public networks.
FTPS adds a TLS encryption layer to the standard FTP protocol. Choose FTPS when existing FTP infrastructure needs encryption without a full protocol change, and where both sides support TLS-enabled FTP. A valid TLS certificate is required on the server side.
SFTP is built on SSH and shares no technical architecture with FTP or FTPS. Choose SFTP for partner-facing or cross-network transfers where built-in SSH encryption, single-port firewall traversal, and SSH key authentication are priorities. No separate certificate authority is required.
Use Cases
Common freight file-transfer patterns
The examples below illustrate how file-transfer integrations are used in freight operations. Whether a specific pattern applies to your implementation depends on your source systems, file formats, and agreed integration scope.
An ERP generates shipment order exports as part of its fulfillment process. A configured file-transfer path can route those files to FTM so transportation records are created from the same source data rather than re-entered by operations staff.
Carriers that provide booking confirmations or pickup confirmations as structured file deposits can be integrated through a file-transfer channel that routes confirmed details back to the corresponding Load record in FTM.
Carriers and billing platforms that deliver freight invoices as structured files can connect to FTM through a file-transfer channel, routing invoice data to the related Load so billing information is associated with the shipment it covers.
A warehouse management system that generates dispatch or load-out exports can feed those files to FTM through a configured channel, keeping the warehouse pick event connected to the freight movement without manual data transfer between teams.
Processing
File handling and exception behavior
Before any mapping takes place, the arriving file is checked for the expected format and structure. Files that do not meet the expected criteria are flagged for exception handling rather than processed partially.
The mapping configuration identifies which source fields are required for a record to be written. How missing required fields are handled (whether the file is rejected, held, or routed for review) is defined during implementation.
The integration can be configured with rules to detect files that share a reference with an existing Salesforce record. Whether duplicates are rejected, merged, or flagged is part of the agreed configuration.
Files that fail processing at any stage are handled according to the exception behavior agreed during implementation. The specific approach (retrying, quarantining, or alerting) depends on the integration design.
BKG-04117.xmlShipmentReference, Origin, DestinationSpecialInstructions field present but not in mapping configuration; skipped per implementation settingsProtocol Reference
FTP, FTPS, and SFTP at a glance
A quick reference for the key differences between the three protocols. The appropriate choice depends on your infrastructure, security requirements, and what your source systems support.
| Attribute | FTP | FTPS | SFTP |
|---|---|---|---|
| Encryption | None by default | TLS (configured) | SSH (inherent) |
| Underlying transport | TCP (port 21 control; data port per mode) | FTP + TLS layer | SSH (default port 22) |
| Authentication | Username and password | Username and password with TLS certificate | Password or SSH key pair |
| Firewall behavior | Multiple ports; passive mode common | Multiple ports; similar to FTP | Single port; simpler to traverse |
| Technical basis | Original FTP standard | FTP extended with TLS | Separate SSH subsystem protocol |
| Typical use context | Controlled internal networks | Existing FTP infrastructure adding security | Partner exchange, cross-network transfer |
Business Benefits
From file drop to connected Salesforce data
A configured file-transfer integration replaces a manual handoff with a structured process. The outcomes below reflect what an FTP file transfer integration is designed to support; specific results depend on your implementation scope.
Freight data from external files reaches FTM through the integration rather than through a person manually copying fields, reducing transcription time and the errors that come with it.
A defined mapping layer applies the same transformation rules to every arriving file, reducing the format inconsistencies that accumulate when the same data is entered by multiple people across multiple sessions.
Rather than silently writing partial or malformed data, a configured integration applies the agreed exception rules: flagging, holding, or rejecting files that do not meet expectations.
When freight files route to Salesforce through a configured channel, the resulting Load records participate in FTM’s existing workflows, reporting, and coordination tools rather than remaining isolated in a file system.
Is FTP the same as SFTP?
No. Despite the similar names, FTP and SFTP are entirely separate protocols with different technical architectures. FTP is the original File Transfer Protocol, using TCP with port 21 as the control port and no encryption by default. SFTP is the SSH File Transfer Protocol, a subsystem of SSH that runs over SSH (default port 22) and encrypts all data inherently.
FTPS is a third option: standard FTP extended with a TLS encryption layer. Choosing between them depends on your source system’s capabilities, your network environment, and your security requirements.
Does the integration support FTP, FTPS, and SFTP?
The transfer protocol used for a file-transfer integration is determined during the integration design phase. The appropriate choice depends on what your source system supports and your organization’s security requirements.
Contact FTM to discuss your specific environment and confirm which protocol options apply to your integration scenario.
What file formats can be transferred?
FTP, FTPS, and SFTP are transport protocols: they transfer whatever files are placed in the agreed directory. The format of those files (XML, EDI, CSV, or another structured format) is a separate concern from the transport mechanism.
The integration configuration determines how the content of arriving files is parsed and mapped to Salesforce fields. The supported formats and the mapping rules are agreed during the integration design phase. Contact FTM to discuss your file format requirements.
How is file retrieval triggered?
How and when the integration retrieves files from the transfer location is part of the implementation configuration. Different integration designs may use polling intervals, event-triggered retrieval, or other approaches depending on the source system’s capabilities and the agreed workflow.
Contact FTM to discuss the retrieval pattern that fits your integration requirements.
Can the integration support bidirectional file exchange?
Whether a file transfer integration includes an outbound path (placing files generated from FTM records into an external system’s transfer location) is a function of the agreed integration scope, not a default behavior.
If your use case requires outbound file generation or a bidirectional exchange, contact FTM to discuss what that involves and whether it applies to your implementation.
What does implementation involve?
FTP file transfer integration is configured to your specific source systems, file formats, and business rules rather than activated from a generic template. Implementation involves agreeing on the protocol, directory structure, file format and naming conventions, field mapping to FTM’s data model, and the exception-handling approach for files that do not process cleanly.
The scope and timeline depend on the number of source systems, the complexity of the field mapping, and whether transformation rules are needed. Contact FTM to start a scoping conversation for your integration.
Get Started
Connect Your Freight Files to Salesforce
FTM’s file transfer integration connects structured freight data from your ERP, WMS, and carrier systems to Salesforce transportation workflows. Talk to the FTM team to scope your integration and define the right configuration.
