Integrating Finance and Operations with Databricks

Databricks and Dynamics 365 Finance and Supply Chain Management get on better than most pairings, for one reason: Microsoft's current export mechanism for F&O writes Delta Parquet, and Delta is Databricks' native table format. The transport problem that dominates integrations with other warehouses mostly disappears. What remains is the choice of export route, the layering of the lakehouse, and the modelling of F&O's data into something analysts can use.

The source: Synapse Link with Delta output

Synapse Link for Dataverse, with F&O tables and entities selected, lands data in an ADLS Gen2 account you control. Configure it to write in Delta Lake format rather than CSV. Once it does, Databricks can mount or reference that storage and read the tables directly, with the change history handled by Delta itself. See Azure Synapse Link for Dataverse for the setup.

The alternatives are weaker for Databricks:

• Link to Fabric puts the data in OneLake. Databricks can read OneLake through its ADLS-compatible endpoint, and Fabric has been adding external table sharing, but it is a detour if Databricks is the destination.
• Export to Data Lake (legacy) is deprecated and wrote CSV. Migrate off it.
• BYOD to Azure SQL then a JDBC read into Databricks works and is common in older estates. It is batch, entity-shaped, and adds a database hop you do not need.

New builds should go Synapse Link with Delta into your own lake. That is the whole transport design.

Layering the lakehouse

The medallion pattern fits F&O data well, and it is worth being explicit about what goes where.

Bronze is the Synapse Link output, read as-is. Do not transform it; do not even copy it if you can avoid it. Register the Delta tables in Unity Catalog as external tables pointing at the Synapse Link container.

Silver is where F&O becomes legible. Enum integers resolved to labels using the enum metadata Synapse Link exports alongside the tables. Financial dimension attribute value sets flattened into columns. Soft-deleted rows and change markers applied so each table is a current-state view. Legal entity (DataAreaId) and partition columns kept consistently. This layer is F&O-specific and needs someone who knows the application.

Gold is the business models: general ledger facts by dimension, inventory on hand and transactions, sales and purchase order lines with status semantics decoded, customer and vendor dimensions. This is where the data team and the finance team argue about what "revenue" means, and it is the layer that Power BI or other tools consume.

The mistake is doing silver-layer work in gold, so every report re-decodes enums, or doing gold-layer work in silver, so the current-state tables carry business logic that changes every quarter.

Change data and deletes

Synapse Link in Delta mode maintains the tables for you, but you still need to understand how updates and deletes are represented if you build any incremental process on top. Delta's change data feed can be enabled on the bronze tables so silver processing picks up only what changed. Test deletes explicitly; a warehouse that never removes cancelled sales lines will overstate everything.

Unity Catalog and access

Register the lake location as an external location in Unity Catalog and grant access through catalog permissions rather than storage keys. F&O's own security, by legal entity and role, does not carry across; rebuild row filters in Unity Catalog on the silver and gold tables where legal entity separation matters. Financial data for one company should not be visible to analysts working for another simply because both live in the same lake.

Compute and cost

Bronze reads are cheap. Silver rebuilds over large tables, particularly inventory transactions and general journal lines, are where compute costs live. Design silver as incremental from the start rather than as a nightly full rebuild that was fine in the pilot and unaffordable in year two.

Sending results back

Some teams want Databricks outputs, such as demand forecasts or customer risk scores, to return to F&O or to Dataverse. There is no reverse Synapse Link. The routes are the Data Management Framework for bulk imports into F&O (see the DMF deep dive), the Dataverse Web API for Dataverse tables, or Dataverse virtual tables over a SQL endpoint if the data only needs to be viewed rather than stored. Keep the write-back narrow; a warehouse that writes operational data back into the ERP has become a second ERP.

What breaks in practice

Entity coverage. Not every F&O data entity is available through Synapse Link. Tables always are, so most teams model from tables and use entities where they exist.

Metadata drift. New fields and new enum values arrive in the lake without ceremony. Silver notebooks that hard-code column lists break; ones that read the exported metadata do not.

Latency misunderstandings. The lake is minutes behind F&O at best. A dashboard labelled "live" will be corrected loudly by the first warehouse supervisor who checks it against the mobile app.

Stability verdict

This is one of the cleaner F&O analytics integrations available today because the formats align. The risk is on the Microsoft side, where the export mechanisms have been reshuffled more than once; keep bronze thin so that if the export route changes again, silver and gold survive. Compare with Fabric and Dynamics 365 if the organisation has not yet committed to Databricks.