Microsoft Dynamics 365 F&O and ServiceNow integration

What moves between them

Most data moves from Microsoft Dynamics 365 F&O into ServiceNow. ml-connector reads vendors, purchase orders, and posted invoice and payment status from Dynamics and writes them into the matching ServiceNow S2P staging tables so procurement and AP teams see current supplier and order data. Invoices that ServiceNow Accounts Payable Operations approves flow the other direction, posting into Dynamics as vendor invoice headers and lines for posting and payment. GL accounts and cost centers are aligned in both directions so every invoice and PO line references a valid account and dimension. Because posted Dynamics ledger entries are read-only over OData, ml-connector never overwrites posted financial records.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For Microsoft Dynamics 365 F&O it requests a client-credentials token from Microsoft Entra ID, scopes it to the customer environment host, and refreshes it when a call returns 401. For ServiceNow it uses OAuth2 client credentials where the admin has enabled the grant, falling back to basic auth, and refreshes the 30-minute token before each sync job. Neither side offers registerable webhooks, so ml-connector polls: Dynamics OData filtered with cross-company and a legal-entity filter, and the ServiceNow Table API filtered on sys_updated_on. Dynamics Business Events can trigger a faster OData read-back where they are configured, but the stub payload still requires a callback for the full record. Writes into ServiceNow use the Import Set API with a coalesce field on the ERP key, and writes into Dynamics rely on the natural invoice key, so a retry updates rather than creates a duplicate. Vendor invoice headers are written before their lines and only before posting, since posted invoices are read-only. Both APIs return HTTP 429 with a Retry-After header, so ml-connector backs off and retries, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized manufacturer with roughly 800 employees runs Microsoft Dynamics 365 F&O for finance and procurement and has rolled out ServiceNow Accounts Payable Operations to give its AP clerks a single queue for invoice intake and approval. Before the integration, clerks looked up vendor and purchase order details in Dynamics, keyed approved invoices into both systems, and reconciled invoice status by hand at month-end. With the two systems connected, vendors and open purchase orders are kept current in ServiceNow from Dynamics, and each invoice approved in ServiceNow posts straight into Dynamics as a vendor invoice. The double entry is gone and AP and finance see the same invoice status without a manual reconciliation step.

What you can do

• •Sync vendors and purchase orders from Microsoft Dynamics 365 F&O into ServiceNow Source-to-Pay staging tables so AP and procurement see current data.
• •Post invoices approved in ServiceNow Accounts Payable Operations back into Dynamics as vendor invoice headers and lines before posting.
• •Keep posted invoice and payment status flowing from Dynamics into ServiceNow so approvers see where each invoice stands.
• •Align GL accounts and cost centers across both systems so every invoice and purchase order line lands on a valid account and dimension.
• •Bridge Microsoft Entra ID client-credentials tokens and ServiceNow OAuth, with polling, coalesce-based upserts, retries, and a full audit trail.

Questions

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

Most data moves from Dynamics into ServiceNow: vendors, purchase orders, and posted invoice and payment status feed the ServiceNow Source-to-Pay staging tables. Invoices approved in ServiceNow Accounts Payable Operations flow the other way and post into Dynamics as vendor invoices. Posted Dynamics ledger entries are read-only over OData, so ml-connector never overwrites them.

How does the integration handle webhooks, since neither system registers them?

Neither side offers a registerable webhook API, so ml-connector polls. It reads Dynamics over OData and the ServiceNow Table API on a schedule, filtering ServiceNow on sys_updated_on for incremental sync. Where Dynamics Business Events are configured they can trigger a faster read-back, but the event payload is only a stub, so ml-connector still calls OData for the full record.

How are duplicate records avoided when a sync retries?

Neither API has an idempotency key. Writes into ServiceNow use the Import Set API with a coalesce field set to the ERP identifier, so a repeated record updates the existing one instead of inserting a second. Writes into Dynamics use the natural invoice key, which causes a duplicate create to error rather than post twice, and ml-connector handles that gracefully on retry.