Connect XML Data to Your Freight Operations in Salesforce
Connect transportation data from your ERP, WMS, and partner systems to FTM through structured XML file exchange, reducing manual entry and keeping shipment information connected.
XML to Salesforce / Illustrative
The Challenge
XML exports that stop at the inbox
ERP systems, warehouse platforms, and trading partners often export shipment data as XML files. Without a structured integration path, those files accumulate in shared drives, email threads, and transfer folders while operations teams re-enter the same data into Salesforce by hand.
The result is duplicated effort, version-control problems, and freight workflows that depend on manual steps instead of connected data.
Shipment data exported from an ERP or WMS as XML has to be rekeyed into Salesforce, introducing errors and consuming dispatcher time on data transfer rather than freight coordination.
Status updates, booking confirmations, and freight invoices from trading partners arrive in one system and never reach the transportation record where they belong.
Date formats, carrier codes, and reference numbers differ across systems. Without a mapping layer, the same data arrives in different shapes and has to be reconciled manually.
Integration Pattern
From XML file to Salesforce transportation record
XML file transfer integration connects structured data files to FTM through a configurable processing pipeline. The specific steps, transfer methods, and exception-handling behavior are agreed upon during implementation.
XML Source
A structured XML file is generated by the source system: an ERP export, a WMS dispatch file, or a partner-provided status document.File Transfer
The file is delivered to an agreed transfer location. The transport method and security configuration are determined during the integration design phase.Parsing and Validation
The XML is parsed and checked for structural correctness. Optional schema validation against an agreed XSD confirms the document conforms to the expected format.Field Mapping
Configured rules translate each XML element to its corresponding Salesforce field. Mapping logic, transformation rules, and exception cases are defined during implementation.Salesforce Record
Mapped data is written to the appropriate Salesforce objects in FTM, connecting the inbound shipment information to the transportation workflow.
Field Mapping
How XML elements become Salesforce fields
Each integration includes a configuration layer that maps source XML elements to their corresponding Salesforce fields. The example below shows a complete freight shipment, using the same fictional reference across both panels.
<FreightShipment> <ShipmentReference>SHP-2025-03811</ShipmentReference> <Origin>Chicago, IL</Origin> <Destination>Dallas, TX</Destination> <PickupDate>2025-03-14</PickupDate> <CarrierCode>ACME</CarrierCode> <WeightLbs>1840</WeightLbs> <!-- Additional fields per agreed schema --> </FreightShipment>
Use Cases
Where XML integration supports freight operations
The following examples illustrate common XML integration patterns for freight. Whether a specific use case applies to your implementation depends on the agreed scope and your system landscape.
An ERP system generates shipment order files as part of its order fulfillment process. An XML integration can route those files to FTM so transportation records are created from the same source data rather than re-entered by hand.
When a WMS generates dispatch or load-out records, an XML export can carry that data to FTM. This keeps the warehouse pick and the freight movement connected without requiring coordinators to transfer information manually between systems.
Trading partners, carriers, or logistics providers may send status updates in XML format. A configured integration can receive those files and apply the relevant status or event information to the corresponding Load record in FTM.
Carriers and billing systems may issue freight invoices as structured XML files. An integration can route invoice data to the related Load record in FTM, connecting billing information to the shipment it covers and reducing reconciliation effort.
Data Quality
XML structure, schema, and exception handling
Every XML file must be well-formed: properly nested elements, matching open and close tags, and consistent encoding. A document that is not well-formed cannot be parsed, regardless of its content. An XML declaration is not required for a document to be well-formed, but the encoding must be handled correctly by the parser.
Where a schema definition (XSD) has been agreed as part of the integration, incoming files can be validated against it before mapping begins. XSD validation is optional and depends on the agreed schema and implementation scope. A document can pass XSD validation and still contain values that require further business-rule checking.
The mapping configuration identifies which source fields are required for a record to be created or updated. How missing required fields are handled depends on the exception-handling approach configured during implementation.
The integration can be configured with rules to detect files or records that share an identifier with an existing Salesforce record. Whether duplicates are rejected, merged, or flagged is part of the implementation configuration.
shipment-SHP-2025-03811.xmlShipmentReference mapped to Load NumberSpecialInstructions present but unmapped; handling per configurationCarrierCode not found in Carrier lookup; exception handling appliesFormat Context
XML, EDI, and APIs: what each one is
These terms appear together in integration discussions, but they describe different things. Understanding the distinction helps set accurate expectations about what an integration involves.
XML is a structured markup format for representing data as a hierarchy of named elements and attributes. It defines how data is written down, not how it is delivered or what it means in a business context.
An XML file can carry any structure its author defines. Two systems can both produce valid XML and still use entirely different element names, hierarchies, and data types. The schema must be agreed between sender and receiver for the exchange to be consistent.
Used for: ERP and WMS exports, configuration files, document exchange, and any context where structured, human-readable data needs to travel between systems.
EDI is a set of standards for structured business document exchange. Standards such as X12 and EDIFACT define specific transaction types (a load tender, a shipment status, an invoice) with agreed field positions and code values.
Unlike XML, EDI does not define a single format: different EDI standards and transaction sets have different structures. What EDI provides is a shared vocabulary for common business transactions, so two trading partners using the same standard can exchange documents without agreeing on a custom schema.
Used for: Established carrier and partner relationships, load tenders, invoices, and acknowledgments where both parties support the same EDI standard.
An API is an interface that allows two applications to communicate directly. APIs do not define a data format: a given API may use XML, JSON, or other structures depending on the provider. APIs can be synchronous or asynchronous depending on their design.
File-based XML exchange and API calls are different integration patterns with different trade-offs. File exchange is well suited to batch processing and systems that already produce export files. An API integration is appropriate where the receiving system needs to respond immediately or where event-driven communication is required.
Used for: System-to-system communication, real-time lookups, and integrations where latency, immediate feedback, or event-driven behavior is a requirement.
Business Outcomes
Less manual work, more connected freight data
Connecting XML data exchange to FTM replaces a manual handoff with a structured process. The outcomes below reflect the benefits an XML file transfer integration is designed to support; specific results depend on the scope and configuration of your implementation.
Shipment data from external systems reaches FTM through the integration rather than through re-entry, reducing the effort required from operations teams and the errors that come with manual transcription.
A defined mapping layer applies the same transformation rules to every file, reducing the field-format inconsistencies that come from manual data entry across multiple users and systems.
A structured file exchange process replaces email threads and shared drives as the mechanism for moving shipment data, creating a more defined path from source system to Salesforce record.
When freight data is in Salesforce, it participates in the workflows, reporting, and coordination tools already built in FTM, rather than sitting in a separate file or external system.
Does FTM require a specific XML schema?
XML is a flexible format and does not inherently conform to any particular business schema. FTM’s XML integration is configured around the schema agreed between the two parties during the integration design phase.
If your source system produces XML in a fixed format, that format becomes the basis for the field mapping configuration. If you have an existing XSD schema definition, it can optionally be used to validate incoming files before mapping begins. Contact FTM to discuss what your source system produces and how that maps to the integration design.
How does field mapping work for XML integration?
Field mapping is configured during implementation. Each element in the source XML document is mapped to its corresponding Salesforce field in FTM. The mapping can include transformation rules, such as converting date formats or standardizing carrier codes, where the source and destination fields use different conventions.
Fields present in the source XML that are not included in the mapping configuration are handled according to the exception-handling approach agreed during implementation. Contact FTM to discuss how your specific XML structure maps to FTM’s data model.
Does the integration support both inbound and outbound XML?
The direction of XML exchange (whether inbound (from an external system to FTM), outbound (from FTM to an external system), or both) is determined by the integration scope agreed during implementation. It is not a default behavior of the XML file transfer capability.
If your use case requires outbound XML generation from FTM records, or a bidirectional exchange, contact FTM to confirm whether that pattern is supported and what it involves.
How are XML files transferred securely?
XML is a data format, not a transport protocol. The security of file transfer depends on the transport method used to deliver the files, not on the XML format itself.
The choice of transport method, its security configuration, and any encryption or authentication requirements are determined during the integration design phase. Contact FTM to discuss your organization’s transfer security requirements.
Can we integrate with a partner system that uses a different XML format?
Because XML is a flexible format rather than a fixed standard, two systems can each produce valid XML with entirely different element names, structures, and data types. An integration between them requires a mapping configuration that translates one format into the other.
The feasibility of integrating with a specific partner format depends on the consistency of that format and the scope of the mapping work involved. Contact FTM to review your partner’s XML format and discuss what an integration would require.
What does implementation involve?
XML file transfer integration is configured rather than activated from a prebuilt template. Implementation involves reviewing your source XML format, agreeing on the field mapping to FTM’s data model, selecting and configuring the transport method, and defining exception-handling behavior for edge cases.
The scope and timeline depend on the complexity of your XML format, the number of source systems, and whether transformation rules are required. Contact FTM to discuss your integration requirements and start a scoping conversation.
Get Started
Connect Your XML Data to Salesforce Transportation Workflows
FTM’s XML file transfer integration connects structured data from your ERP, WMS, and partner systems to freight operations in Salesforce. Talk to the FTM team to scope your integration and define the right mapping configuration.
