How to Integrate a TMS with Dynamics 365: 6 Steps

Connecting a best-of-breed TMS to Microsoft Dynamics 365 Supply Chain Management isn't a lift-and-shift exercise. It's a deliberate wiring job across OData entities, the Data Management Framework, Business Events, and the rating engine API that Microsoft built specifically for this purpose. This guide walks through a TMS Dynamics 365 integration end to end: what to set up before you touch any code, the six steps that get data flowing in both directions, and the failure modes that trip up teams who skip the validation phase.

Why shippers running Dynamics 365 still need an external TMS

Dynamics 365 Supply Chain Management isn't thin on transportation functionality. Dynamics 365 Supply Chain Management includes transportation management capabilities for rate shopping, load building, tendering, freight reconciliation, and inbound and outbound transportation planning. Transportation management handles carrier selection, route planning, freight rating, and load building for both inbound and outbound shipments, integrating with third-party carriers and 3PLs so logistics teams get a single screen to compare shipping costs and delivery windows before a shipment leaves the warehouse.

The gap shows up once you move past a handful of contracted carriers. The bigger question for many organizations is carrier connectivity, because F&SCM does not include the rate engines needed to connect those workflows to individual carriers, so companies must build or acquire them and maintain them as carrier requirements change. Microsoft didn't leave this to chance, though. The rate route workbench supports rate shopping across carriers and modes, with flexible rating through the rating engine and support for volumetric weight, and Microsoft also exposes a rating engine API for integration with external parties. That's the signal worth paying attention to: Dynamics 365 transportation management was designed to be extended, not replaced wholesale.

This is why MercuryGate, Descartes, Manhattan Active, and Oracle TM all show up as common D365 integration partners on tenders for €10M+ transport spend shippers. Cargoson fits a slightly different slot in that list: a carrier-connectivity layer for shippers who want multi-carrier reach across road, parcel, sea and air without opening a full TMS replacement project.

What you need before you start

Before anyone writes a line of integration code, get these in place: admin access to both your D365 F&SCM sandbox and production environments, an Entra ID (formerly Azure AD) app registration capable of issuing OAuth tokens, and a TMS or carrier-connectivity platform that supports REST or OData calls on its side. You'll also need clarity on integration ownership, meaning which party configures F&SCM endpoints and data entities and which owns the freight platform side of the connection. This sounds bureaucratic until the first sync failure happens and nobody knows whose job it is to fix it.

There are three distinct integration surfaces available, and picking the wrong one for the job is the most common early mistake. A connected freight platform integrates with Supply Chain Management through the Data Management Framework or direct API integration, and the transportation management module's rating engine API is also designed for integration with external parties. Here's how Microsoft's own interface options stack up for throughput and real-time capability:

These interface characteristics come straight from Microsoft's own integration documentation, and the pattern is worth memorizing before you design anything: batch-friendly surfaces for high-volume, low-urgency data, and Business Events for anything that needs to trigger an action the moment it happens.

Map your required objects before step one. At minimum you'll be moving sales and purchase order headers, shipment and load records, carrier master data, and freight rate tables between the two systems.

Connecting the systems: six steps

1. Map your data flow. Decide explicitly which records move from D365 to the TMS (orders, shipments, delivery dates) and which move from the TMS back to D365 (carrier rates, booking confirmations, tracking events, freight invoices). Write this down as a table before any configuration starts. Most integration rework traces back to an assumption nobody checked at this stage.
2. Register an app in Microsoft Entra ID. Generate the OAuth client ID and secret your TMS will use to authenticate against D365's APIs. Grant it only the data entity permissions it needs, scoped to the legal entities relevant to your transport operation.
3. Choose your integration surface per data flow. For bulk, scheduled exchanges, such as nightly freight rate table updates, use the Data Management Framework or the Recurring Integrations API. For anything that needs to fire the moment a sales order is confirmed, use Business Events instead, since recurring integrations rely on asynchronous, queue-based handling with limited flexibility, not suitable for real-time scenarios, while Business Events provide real-time capability through a modern event architecture.
4. Connect the rating engine API. This is the piece that lets external rate shopping results land in D365's native freight bill and reconciliation screens rather than sitting in a disconnected spreadsheet. Order and shipment data moves to the freight platform, where rating against maintained carrier connections, carrier selection, booking, document generation, and tracking take place, carrier, service-level, and tracking data then moves back into the ERP, and where freight audit and AP workflows are configured, validated freight cost can return to the ERP's financial processes. Note that for small parcel shipping specifically, Microsoft states that the organization develops the rate engine in collaboration with the carrier or a carrier hub service, which returns a label, a rate, and a tracking number, so parcel and LTL/FTL rating may need separate engine configurations.
5. Subscribe to Business Events on the TMS side. Wire up triggers such as sales order confirmed or shipment created so the TMS fires carrier booking and document generation automatically, instead of polling D365 on a schedule and missing the gap between polls.
6. Run parallel test shipments in the sandbox. Push one inbound order and one outbound order through the full chain. Confirm carrier selection fires correctly, tracking status updates land back in D365 without manual intervention, and the freight invoice reconciles against the expected rate before you touch production traffic.

How to confirm the integration actually works

You know the integration is live when three things happen without anyone touching a keyboard: the order appears in the TMS shortly after D365 confirms it, tracking status updates post back automatically, and the freight invoice matches the rate quoted at booking. If any of those three requires a manual nudge, something in steps 3 through 5 above is misconfigured, not just slow.

For shippers with older EDI-heavy carrier networks already plugged into D365 through tools like SEEBURGER's BIS platform, middleware can act as the bridge rather than connecting the TMS directly to D365's APIs. That's a legitimate fallback, not a workaround to be embarrassed about, especially where B2B document exchange with carriers is already standardized through an existing EDI platform.

Common failure mode: duplicate bookings and silent sync gaps

The failure that costs real money isn't a hard error, it's the silent one. A carrier booking API call times out, the TMS retries automatically, and without protection you end up with two bookings for one shipment, two labels printed, and a freight invoice dispute three weeks later. The fix is an idempotency key attached to every write operation: a unique identifier the TMS passes with each booking request so that D365, or the carrier API behind it, recognizes a retry as the same request rather than a new one. Write-actions should be designed to be idempotent, so if a system tries the same action twice, it detects the duplicate request key and prevents double-processing.

Pair that with logging discipline. Attach a correlation ID to every API call and webhook delivery, reconcile daily against the D365 freight bill table, and set alerting on any failed Business Event delivery rather than discovering the gap during month-end freight audit. Since Business Events require external systems to consume and process them correctly, a silent subscriber failure on the TMS side won't throw an error in D365, it just stops updating. Alerting is the only way you'll catch it before your controller does.

EDI vs API: when you still need both

Not every carrier in a European network speaks REST. REST APIs are the modern default for new carrier and logistics SaaS connections, JSON-based and well documented, and FedEx, UPS, DHL, and most current TMS platforms expose REST endpoints. But the limit is coverage, since many legacy carriers still have no REST option, and in Europe that gap often sits with regional LTL and rail operators rather than the global parcel networks.

Format adds another layer specific to this market. X12 dominates US domestic freight, while EDIFACT dominates cross-border and ocean trade, which matters directly for European shippers moving freight across borders or by sea, where EDIFACT messages for invoices and customs documents may still be the only option a carrier supports. A realistic architecture combines REST for the carriers that offer it, EDI for the ones that don't, and a documented manual fallback for whatever's left, rather than assuming one protocol will cover the network.

Choosing the right integration partner

How you connect depends on carrier mix and internal engineering capacity more than on preference. A direct API integration against the rating engine suits teams with development resources and a contained carrier list. Middleware such as SEEBURGER BIS suits teams with heavy EDI dependency across customs and cross-border documents. A carrier-connectivity layer like Cargoson, MercuryGate, Descartes, or Manhattan Active suits teams that want multi-carrier reach without owning the rate engine maintenance burden in-house.

Start with the data flow map from step one above, confirm which interface each flow actually needs rather than defaulting to whichever one your TMS vendor demoed first, and run the sandbox test before you touch a single production carrier contract.