EDI File Transfer for Freight Operations, Connected to Salesforce
Connect your transportation workflows with external ERPs, WMS platforms, and carrier systems through structured file exchange. Reduce duplicate entry, eliminate disconnected shipment records, and keep freight data coordinated inside Salesforce.
File Exchange to Salesforce
/ Carrier System
File Transfer
Salesforce Load
| Source field | → | Salesforce field | Map |
|---|---|---|---|
| ShipRef_ID | → | Load Number | |
| OriginFacility | → | Origin Location | |
| DestZip | → | Destination | |
| PickupDT | → | Pickup Date | |
| CarrierRef | → | Carrier Reference | |
| ShipStatus | → | Load Status |
Disconnected systems slow your freight operations
When shipment data lives in separate systems, operations teams spend time rekeying information and reconciling records that should match automatically.
Manual file handling
Shipment files arrive by email or shared drive. Staff download, interpret, and re-enter data into Salesforce by hand, introducing errors at every step.
Duplicate entry across platforms
The same Load information is entered in your ERP, your WMS, and your TMS separately. A change in one system rarely propagates to the others automatically.
Inconsistent shipment references
Each system assigns its own shipment identifiers. Matching a carrier reference to a Salesforce Load record requires manual lookup or a spreadsheet intermediary.
Disconnected status updates
Pickup confirmations, in-transit milestones, and delivery notifications sit in a separate carrier portal rather than updating your Salesforce Load records in context.
From source document to Salesforce transportation record
Structured file exchange gives freight data a defined path from your partner systems into the correct fields in Salesforce, with validation and error handling at each stage.
Source data is prepared
A trading partner, ERP, or WMS produces a structured file, such as an EDI transaction set, an XML document, or a delimited file, containing shipment details like origin, destination, pickup date, and carrier reference.
File is transmitted
The file is delivered via a configured transfer method. The specific transfer mechanism, whether a direct file drop, FTP, or another approach, is agreed upon during implementation based on your existing infrastructure.
Validation and field mapping
Incoming records are validated against expected field formats. Configured field mappings translate source identifiers into Salesforce field names. Records with missing required fields are separated for review before any write occurs.
Salesforce transportation records created or updated
Validated records are written to the appropriate Salesforce objects: Load records, carrier records, or shipment details within FTM. The result reflects the inbound data without manual entry.
Downstream workflows proceed
With load and shipment data in Salesforce, dispatch workflows, carrier assignments, status tracking, and invoicing proceed from the file exchange data rather than a manual re-entry step.
Common freight documents in structured file exchange
Common freight document types exchanged between shippers, carriers, and logistics platforms. Support for each depends on your integration scope and what your trading partners produce.
Shipment Instructions
Origin, destination, commodity, weight, and pickup window sent from shipper to carrier before the load moves.
Available for IntegrationShipment Status Updates
In-transit milestones, estimated arrival, pickup confirmation, and delivery confirmation from carrier back to shipper.
Available for IntegrationFreight Invoices
Carrier-issued invoices detailing charges, accessorials, and payment terms, matched against the Load record for reconciliation.
Available for IntegrationAcknowledgments
Functional acknowledgment confirming that a transmitted file was received and structurally accepted by the receiving system.
Available for IntegrationIndustry-standard X12 freight transaction sets
EDI uses defined transaction sets to represent specific document types. The sets below are widely used in freight logistics. Whether a specific transaction set is configured as part of an FTM integration depends on your implementation scope and trading partner requirements.
| Set | Name | Industry purpose | FTM status |
|---|---|---|---|
| 204 | Motor Carrier Load Tender | Shipper sends load details and pickup instructions to a carrier, requesting service for a specific shipment. | Available for Integration |
| 214 | Transportation Carrier Shipment Status | Carrier returns status updates, including pickup, in-transit milestones, and delivery confirmation. | Available for Integration |
| 210 | Motor Carrier Freight Invoice | Carrier-issued invoice for freight charges, matched against Load records for reconciliation and payment processing. | Available for Integration |
| 997 | Functional Acknowledgment | Response confirming receipt and structural validity of a transmitted EDI file. Does not confirm processing or business acceptance. | Available for Integration |
Source fields mapped into Salesforce Load records
The mapping layer translates structured file fields into the correct Salesforce objects. Mapping is configured during implementation; the handling of unmapped or unrecognized fields depends on the exception-handling approach agreed upon during that process.
Connection and file transfer options
The file format and the delivery mechanism are separate decisions. FTM lists EDI file transfer, XML file transfer, and FTP file transfer as Data Exchange integration categories. The method used in your implementation depends on your infrastructure and trading partner capabilities.
EDI File Exchange
AvailableElectronic Data Interchange uses structured transaction sets, such as X12 formats, to represent standard freight documents. EDI is a data standard, not a delivery mechanism, and is transmitted via a separately agreed-upon transport layer.
XML File Transfer
AvailableXML-based files offer a human-readable, schema-driven alternative to fixed-format EDI. Many ERP and WMS platforms export data in XML. FTM lists XML file transfer as a Data Exchange integration category.
FTP File Transfer
AvailableFTP is a file transport protocol that provides a delivery path for EDI, XML, CSV, or other structured files between systems. SFTP is a separate protocol that operates over SSH and provides an encrypted transport path; it is not a variant of FTP. The choice of transport method and its security configuration is determined during implementation.
When records do not map cleanly
Not every inbound file produces a clean Salesforce record on the first pass. A well-configured integration separates exception handling from normal processing so that errors are surfaced rather than silently skipped.
Rejected records
Records that fail structural validation, such as an unrecognized segment or a missing required field, are held out of the Salesforce write and logged for review. The extent of automated rejection handling depends on your implementation configuration.
Missing required fields
Salesforce enforces field-level validation rules. If an inbound record is missing a value that Salesforce requires, the record is not created. How that failure is surfaced for review depends on the exception-handling approach configured during implementation.
Duplicate shipment references
If an incoming record references a Load number or shipment ID that already exists in Salesforce, the handling, whether to update, skip, or flag, is determined by the duplicate rule configuration set up during implementation.
Mapping errors
If a source field value does not match the expected format for the mapped Salesforce field, the affected record cannot be written to Salesforce. How mapping errors are captured and reviewed is part of the exception-handling configuration defined during implementation.
EDI file exchange vs. API integration
Both file-based exchange and direct API integration move freight data into Salesforce. The right approach depends on your trading partners, infrastructure, and timing requirements.
EDI and structured file exchange
Batch-oriented, format-driven, standard across legacy and modern trading partners
Direct API integration
Event-driven, near-real-time, requires a partner system with an accessible API
What improves when freight data flows consistently
Less manual entry
Shipment instructions, status updates, and invoices arrive in Salesforce Load records through the configured file exchange rather than manual re-keying.
More consistent freight records
Load numbers, carrier references, and shipment fields carry a single source of truth across Salesforce rather than varying by which person entered them.
Improved partner connectivity
Trading partners that require structured file exchange have a defined path for data to reach Salesforce without manual steps in between.
Fewer reconciliation steps
When invoices and shipment status data arrive through a structured path, matching them to Salesforce Load records requires fewer manual cross-checks.
Audit trail by design
A structured file exchange process creates a defined record of which files were received and processed. Exception-handling configuration determines how failed records are separated and surfaced for review.
Legacy system compatibility
Partners and platforms that do not support modern REST APIs can still send structured data through file-based exchange without requiring a systems overhaul.
More ways to connect FTM to your systems
Frequently asked questions
What file formats does FTM support for structured file exchange?
FTM lists EDI file transfer, XML file transfer, and FTP file transfer as Data Exchange integration categories. For CSV and delimited formats, Salesforce provides native import tools that support a range of standard and custom objects. Whether CSV-based imports are part of your FTM integration scope depends on your implementation.
The formats configured in a specific integration depend on what your trading partners produce and your data requirements. Contact FTM to confirm which formats apply to your environment.
Does FTM support specific EDI transaction sets like 204 or 214?
X12 204 (Motor Carrier Load Tender), 214 (Shipment Status), 210 (Freight Invoice), and 997 (Functional Acknowledgment) are widely used industry-standard transaction sets in freight logistics. Whether a specific transaction set is implemented within your FTM integration depends on your trading partner requirements and the scope agreed upon during implementation.
Contact FTM to discuss which transaction sets your environment requires and how they would be configured.
How are trading partners onboarded for EDI exchange with FTM?
Trading partner onboarding is handled as part of the implementation process. This involves agreeing on the file format, field definitions, transfer method, and error handling approach with each partner before data flows begin.
Timeline depends on format complexity and the number of partners. Contact FTM to discuss your situation and get an accurate picture of what onboarding involves.
How is file security handled during transfer?
The security measures applied during file transfer, such as encryption in transit, secure transfer protocols, or access controls, depend on the transfer method configured for your implementation. SFTP, for example, provides an encrypted transport layer when used as the delivery mechanism.
Specific security requirements should be discussed with FTM’s implementation team to confirm what applies to your infrastructure and what your trading partners support.
How does field mapping work between an inbound file and Salesforce?
For structured EDI and XML exchange, field mapping is configured at implementation time. Each source field in the inbound file is mapped to the corresponding Salesforce field API name on the target object. Unmapped fields and exception cases are handled according to the approach configured during implementation.
For CSV imports using Salesforce’s native import tools, Salesforce provides field-matching assistance and skips columns that do not match a target field. Whether CSV-based imports form part of an FTM EDI integration depends on the scope of your implementation. Contact FTM to discuss how field mapping applies to your specific setup.
How long does an EDI file transfer integration take to implement?
Timelines vary based on the number of trading partners, the complexity of the file formats, and the field mapping scope. A single-partner integration with a straightforward format takes less time than one involving multiple partners with custom exception-handling logic.
Contact FTM to discuss your requirements and get an estimate for your situation.
Connect Freight Data to Your Salesforce Workflows
Structured file exchange gives your trading partners a reliable path into Salesforce without manual steps. Talk to FTM about what an EDI or file transfer integration looks like for your environment.
