Microsoft Dynamics 365 F&O and Orderful integration

What moves between them

Documents move in both directions. Outbound, ml-connector reads confirmed purchase orders and posted vendor invoices from Microsoft Dynamics 365 F&O and creates them in Orderful as 850 and 810 transactions addressed to the matching trading partner. Inbound, it reads 855 purchase order acknowledgments, 856 ship notices, and 810 supplier invoices from Orderful and writes them into the matching D365 entities, updating purchase order status and staging vendor invoices. Item numbers, units of measure, and partner identifiers are aligned on both sides so every transaction line resolves to a real D365 product and a configured ISA ID. The order and finance records of record stay in D365, since Orderful only routes the documents.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the D365 side it requests an Entra ID OAuth token with the client credentials flow and refreshes it before the one-hour expiry, scoping each call to the correct legal entity with cross-company and a dataAreaId filter. On the Orderful side it sends the static orderful-api-key header and stamps each transaction with the sender and receiver ISA IDs, which must already exist as trading partner relationships or routing fails. Business Events in D365 are treated as a trigger only, because the payload is a stub, so the handler reads the full purchase order or invoice back over OData and dedupes on the event ControlNumber. D365 has no idempotency key, so writes use the natural keys such as PurchaseOrderNumber with dataAreaId, and a BullMQ jobId guards against double-posting an inbound document. Inbound transactions are taken by HTTP push, where the endpoint returns 200 once written or 202 if it needs time, or by polling buckets where no public endpoint exists. The stream flag is held at test until partner testing is done, then flipped to live. Financial dimensions are written as the configured display string, transaction IDs are handled as 64-bit values, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized consumer goods manufacturer with about 500 employees runs Microsoft Dynamics 365 F&O for procurement, production, and finance, and supplies several large retailers that mandate EDI. Before the integration, a coordinator printed each confirmed purchase order from D365 and keyed it into a partner portal, then typed returning acknowledgments, ship notices, and supplier invoices back into D365 by hand, which delayed orders and produced chargebacks when a document was late or mismatched. With Microsoft Dynamics 365 F&O and Orderful connected, each confirmed purchase order leaves as an 850 within the polling window, the 855 and 856 update the order automatically, and supplier invoices arrive as 810 transactions ready to post. The re-keying stops and the compliance chargebacks go away.

What you can do

• •Send confirmed Microsoft Dynamics 365 F&O purchase orders to Orderful as 850 transactions addressed to the right trading partner.
• •Send posted D365 vendor invoices to Orderful as 810 transactions for partner delivery.
• •Write inbound 855 acknowledgments and 856 ship notices from Orderful back into D365, updating purchase order status.
• •Bridge the Entra ID OAuth token and the static Orderful API key, and map D365 item numbers to EDI line references and partner ISA IDs.
• •Hold the stream flag at test until go-live, with jobId dedup, retries, and a full audit trail on every transaction.

Questions

Which documents move between Microsoft Dynamics 365 F&O and Orderful, and in which direction?

Documents flow both ways. Outbound, confirmed purchase orders and posted vendor invoices leave D365 as 850 and 810 EDI transactions through Orderful. Inbound, 855 acknowledgments, 856 ship notices, and 810 supplier invoices come back from Orderful and update or stage the matching D365 records. Orderful only routes the documents, so the order and finance records of record stay in Microsoft Dynamics 365 F&O.

Does D365 push records to the integration, or does ml-connector poll for them?

D365 can fire a Business Event such as purchase order confirmed, but the payload is only a stub of identifiers, so ml-connector treats it as a trigger and reads the full record back over OData, deduplicating on the event ControlNumber. Where Business Events are not enabled, it polls the OData entities on a schedule you set. On the Orderful side, inbound transactions arrive by HTTP push or by polling buckets when no public endpoint is available.

How does the integration handle authentication across the two systems?

The two systems use very different schemes. Microsoft Dynamics 365 F&O requires an OAuth 2.0 Bearer token from Microsoft Entra ID using the client credentials flow, which ml-connector refreshes before its roughly one-hour expiry, while Orderful uses a single static orderful-api-key header with no refresh. ml-connector stores both encrypted and presents the right credential to each side on every call, and it tags each Orderful transaction with the configured sender and receiver ISA IDs so routing succeeds.