Microsoft Dynamics 365 F&O and Looker integration

What moves between them

The flow runs from Looker into Microsoft Dynamics 365 F&O. ml-connector runs a Looker query or saved Look against a LookML model, reads the returned rows, and posts them into Dynamics 365 as journal lines against the matching main accounts and financial dimensions. This is driven on a schedule because Looker emits no change events, and a Looker scheduled plan can also POST the same result set to ml-connector to trigger a run as soon as the delivery fires. Looker is read-only for finance data, so ml-connector never writes invoices, payments, or any transaction back into Looker. Posted Dynamics 365 ledger entries are read-only, so totals are written through the journal entities, not edited in place.

How ml-connector handles it

ml-connector stores both credential sets encrypted and bridges two different auth styles. For Looker it posts client_id and client_secret to the login endpoint, caches the one-hour token, and sends it as token rather than Bearer, re-authenticating on a 401. For Dynamics 365 it requests an Entra ID client credentials token scoped to the environment host and sends it as a Bearer token, refreshing each hour. Because Looker has no change stream, ml-connector polls by running the configured query on your cadence, and where a scheduled plan is set up it accepts the pushed delivery on an ingest path secured by a secret in the URL since Looker sends no signature. Running a meaningful query needs the model, explore, and field names from the customer LookML, which are configured per instance because there is no standard schema. Looker query results cap at 5000 rows per call, so larger extracts use the offset loop or an async query task. Main accounts and financial dimensions are mapped first, so every Dynamics 365 journal line references a value that already exists. Dynamics 365 returns 429 with Retry-After under service protection limits and Looker returns 429 near 60 requests per minute, so ml-connector backs off and retries, and since OData has no idempotency key it relies on natural keys to avoid duplicate journals. Every record carries a full audit trail and can be replayed if a Dynamics 365 post fails.

A real-world example

A mid-sized retail company with around 600 staff runs Microsoft Dynamics 365 F&O for finance and procurement and has its sales and channel data modeled in Looker on top of a warehouse. The accounting team needs a weekly marketplace fee and commission allocation that is only calculated in a LookML model, and before the integration an analyst exported the Look to a spreadsheet every Monday and a clerk keyed the totals into Dynamics 365 by cost center, which delayed the close and introduced typos. With the two connected, ml-connector runs the Look, splits the result across the correct main accounts and financial dimensions, and posts the journal into Dynamics 365 automatically. The manual export and re-keying step is gone and the allocation posts on time every week.

What you can do

• •Run Looker queries and saved Looks against your LookML model and post the results into Microsoft Dynamics 365 F&O as journal lines.
• •Map Looker result columns to Dynamics 365 main accounts and financial dimensions so every line lands on a valid account.
• •Bridge Looker token login auth and the Dynamics 365 Microsoft Entra ID bearer token, re-authenticating each on expiry or a 401.
• •Accept Looker scheduled plan webhook deliveries on a secret ingest path, or poll on your own cadence since Looker has no change events.
• •Back off and retry on the Dynamics 365 and Looker 429 limits, with a full audit trail and replay on every record.

Questions

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

The flow is Looker into Microsoft Dynamics 365 F&O. ml-connector runs a Looker query or Look, reads the returned rows, and posts them into the Dynamics 365 general ledger as journal lines. Looker is a read-only BI layer with no native transaction objects, so ml-connector never writes invoices, payments, or other records back into Looker.

Can ml-connector write invoices or purchase orders into Looker?

No. Looker is an analytics layer over a data warehouse and has no native invoice, purchase order, vendor, or GL account objects. What it provides is query execution against your LookML models plus content, user, and scheduled plan management. ml-connector uses that query path to pull modeled financial summaries out of Looker and writes them into Dynamics 365, not the other way around.

How does the integration get data out of Looker without change events?

Looker has no record created or updated event stream, so ml-connector polls by running the configured query on the cadence you set. Where a Looker scheduled plan is set up, it can also POST the result set to an ml-connector ingest path on a cron. That path is secured with a secret in the URL because Looker sends no signature header on scheduled deliveries.