Microsoft Dynamics 365 F&O and JAGGAER integration

What moves between them

Master data flows from Microsoft Dynamics 365 F&O into JAGGAER: vendors, main accounts, financial dimensions, catalog items, and confirmed purchase orders, so buyers and approvers work against current ERP records. Approved AP invoices flow back from JAGGAER into D365, where ml-connector creates VendorInvoiceHeaders and VendorInvoiceLines before they are posted. Invoice approval status moves JAGGAER to ERP with each invoice, while GL accounts and dimensions move ERP to JAGGAER as read-only coding values. Master data syncs on a schedule, and a D365 business event on purchase order confirmation can trigger a faster push.

How ml-connector handles it

ml-connector stores both credential sets encrypted and runs two separate OAuth2 client-credential token cycles, one against Microsoft Entra ID for the environment .default scope and one against the JAGGAER Keycloak J1p-integrations realm, refreshing each Bearer token as it nears its roughly one-hour life. It accepts each customer's full tenant host on both sides, since neither system has a shared base URL, and pins the D365 legal entity with dataAreaId so vendors and accounts come from the right company. GL accounts and dimensions are mapped first so an invoice coded in JAGGAER references a MainAccount and dimension combination that already exists in D365. Approved invoices are matched to their JAGGAER supplier invoice number for dedup, then written as a VendorInvoiceHeader followed by lines, and only before posting, since posted vendor invoices are read-only over OData. Because the J1P API is pull-only, JAGGAER is polled for new approved invoices on a schedule, while a D365 purchase order confirmed business event can push that PO into JAGGAER sooner; the event payload is a stub, so ml-connector calls back to OData for the full record. D365 service protection returns HTTP 429 with Retry-After, so it backs off and retries, and every record carries a full audit trail and can be replayed if a write fails.

A real-world example

A mid-sized public-sector agency runs Microsoft Dynamics 365 F&O for financials and procurement and adopts JAGGAER to give departments a guided requisition and supplier portal. Before the integration, staff rekeyed new vendors and chart-of-accounts changes into JAGGAER by hand, and approved invoices were typed back into D365 each week, which delayed coding and caused mismatched account numbers. With the two systems connected, vendors, accounts, and dimensions stay current in JAGGAER automatically, and each approved invoice lands in D365 as a vendor invoice coded to valid accounts. Approvers see accurate options, and the AP team stops re-entering invoices.

What you can do

• •Send Microsoft Dynamics 365 F&O vendors, main accounts, and financial dimensions into JAGGAER as procurement and coding master data.
• •Push confirmed D365 purchase orders into JAGGAER, triggered by a purchase order confirmed business event or on a schedule.
• •Write JAGGAER approved invoices into D365 as VendorInvoiceHeaders and lines before posting, deduped by supplier invoice number.
• •Run separate OAuth2 client-credential token cycles for Microsoft Entra ID and the JAGGAER Keycloak J1p-integrations realm.
• •Poll JAGGAER for approved invoices on a schedule, with Retry-After handling, a full audit trail, and error replay on every record.

Questions

Which direction does data move between Microsoft Dynamics 365 F&O and JAGGAER?

Master data moves from D365 into JAGGAER: vendors, main accounts, dimensions, catalog items, and confirmed purchase orders. Approved AP invoices and their status move back from JAGGAER into D365, where ml-connector writes them as VendorInvoiceHeaders and lines. GL accounts and dimensions are read-only inside JAGGAER, used only for invoice coding.

How does the integration bridge authentication between the two systems?

Both systems use OAuth2 client credentials, but against different identity providers. D365 F&O issues a Bearer token through Microsoft Entra ID scoped to the environment host, while JAGGAER issues one through a Keycloak realm named J1p-integrations on its own instance. ml-connector runs both token cycles, stores the secrets encrypted, and refreshes each token as it nears its roughly one-hour expiry.

Can invoices be written into Dynamics 365 F&O after they are posted?

No. The VendorInvoiceHeader entity over OData only accepts writes before an invoice is posted, so ml-connector creates the header and lines from a JAGGAER approved invoice in the pre-posting window. Because OData writes have no idempotency key and rely on natural keys, it matches the JAGGAER supplier invoice number first to avoid creating a duplicate.