Microsoft Dynamics NAV and Databricks integration

What moves between them

Purchase orders, sales orders, and general ledger entries flow from Microsoft Dynamics NAV into Databricks tables on a schedule you define. NAV is the source of truth; Databricks is append-only, so existing records are not updated, only new records are pushed. The mapping is straightforward: NAV document numbers, dates, line items, amounts, and account codes land in corresponding Databricks table columns. Because NAV has no purchase order webhook, ml-connector polls the NAV API at your chosen interval.

How ml-connector handles it

ml-connector stores both credential sets encrypted and refreshes the Entra ID bearer token before it expires, protecting against auth failures mid-sync. It accepts the NAV tenant ID and company ID and the Databricks workspace URL to route API calls to the correct Databricks instance across AWS, Azure, or GCP. Since NAV is pull-only for purchase orders and Databricks is write-only, the sync is unidirectional. ml-connector fetches changed records from NAV since the last successful run, maps each record to the Databricks table schema, and submits a SQL INSERT via the Jobs API rather than writing metadata directly, ensuring data lands in the table you expect. It tracks which records were pushed, retries on transient failures like network timeouts, and logs every record's source NAV ID and target Databricks table for troubleshooting.

A real-world example

A mid-sized distributor runs Microsoft Dynamics NAV for order management and accounting, and uses Databricks on Azure for financial analytics and reporting. Before the integration, the finance team exported purchase orders and GL entries from NAV to CSV each week, uploaded to Databricks manually, and reconciled column names and data types by hand. With NAV and Databricks connected, each week's purchase orders and GL postings flow automatically into Databricks tables, ready for downstream analytics without manual export or transformation. The BI team builds dashboards off the live tables without waiting for weekly batch exports.

What you can do

• •Extract purchase orders, sales orders, and general ledger entries from Microsoft Dynamics NAV on a polling schedule.
• •Write records into Databricks tables via SQL INSERT, preserving source NAV document IDs and timestamps.
• •Refresh Entra ID bearer tokens automatically and handle workspace-specific Databricks base URLs across AWS, Azure, or GCP.
• •Maintain a full audit trail for every record showing source NAV ID, target table name, and sync timestamp.
• •Retry on transient failures and alert on schema mismatches or missing target tables.

Questions

Why does ml-connector poll Microsoft Dynamics NAV instead of using webhooks?

NAV webhooks expire after 3 days and must be renewed manually. More critically, purchase orders are not available in NAV's standard webhook list, so polling is the only way to reliably capture them. ml-connector polls at your chosen interval and tracks the last successful run to pick up only new or changed records.

Can ml-connector write data back to Microsoft Dynamics NAV from Databricks?

No. This integration is read-only from NAV to Databricks. Databricks serves as a data platform for analytics; it has no financial objects like invoices or GL accounts, so write-back would require manual transformation and is not part of this connector pair. If you need bidirectional sync, that would require a separate flow from Databricks to NAV.

What happens if the Databricks target table is missing or the schema doesn't match?

ml-connector validates the table schema before writing and stops the sync with an error if the table is missing or columns don't match. You define the target table structure once, and ml-connector will alert if records arrive with unexpected field types, letting you fix the schema before data lands in the wrong shape.