Integrating Finance and Operations with Snowflake

Snowflake is the enterprise data warehouse many organisations have already standardised on before they arrive at Dynamics 365 Finance and Supply Chain Management. Microsoft would prefer that your analytics lived in Fabric. The data team has a Snowflake contract, hundreds of models, and no intention of moving. So the practical question is how F&O data gets into Snowflake with the least friction, and the honest answer is that there is no direct connector and you will be assembling a pipeline from Microsoft's export mechanisms plus a transport step.

Step one: get the data out of F&O

F&O does not expose its database for direct querying in the cloud. Every route starts with one of Microsoft's export mechanisms, and the choice among them has been changing over the last few years.

Synapse Link for Dataverse with F&O tables and entities. The current strategic route. F&O tables and data entities are made available through Dataverse and land as Delta Parquet in an Azure Data Lake Storage Gen2 account you own, refreshed continuously. This is what Microsoft wants you to use and the one that will keep receiving investment. See Azure Synapse Link for Dataverse.

Link to Microsoft Fabric. The same underlying mechanism landing in OneLake instead of your own storage account, with no copy of the data. Excellent if Fabric is your warehouse; less useful as a stepping stone to Snowflake, although OneLake can be read externally as ADLS-compatible storage.

Export to Data Lake (legacy). The older F&O feature that wrote CSV to a data lake. Deprecated in favour of Synapse Link. If you are on it, plan the move; do not build new Snowflake pipelines on it. Our data lake export for Finance guide covers the history.

BYOD (bring your own database). Data entities exported to an Azure SQL database on a schedule. Still works, still supported, and still the route many existing Snowflake integrations use because it produces clean entity-shaped tables. Batch-only, entity-only, and the export jobs need babysitting.

Data entities over OData. Fine for small reference tables. Not a bulk route.

For a new build in 2026, Synapse Link to your own ADLS Gen2 is the default. BYOD is the pragmatic choice if your team already runs it and needs entity shapes rather than raw tables.

Step two: move it into Snowflake

From ADLS Gen2, there are two sensible transports.

Snowflake's own external stages and Snowpipe. Snowflake can read directly from ADLS Gen2 through an external stage using a storage integration. Point it at the Synapse Link output, define external tables or use Snowpipe for continuous loading of the Parquet files, and the data team stays inside tools they know. This is the lowest-moving-parts option.

Azure Data Factory or Synapse pipelines. ADF has a native Snowflake connector and can orchestrate incremental copies, apply light transformation, and handle the change-data-capture folders Synapse Link produces. Use it when the data team wants Microsoft-side orchestration or when the load needs logic beyond "copy the files". See Azure Data Factory with Dynamics 365.

Either way, treat the lake as the handover point. F&O writes to the lake; Snowflake reads from the lake; nobody writes a pipeline that talks to F&O directly.

The modelling work is the real cost

F&O tables are not analyst-friendly. Enum values arrive as integers, financial dimensions are stored in a normalised structure that needs joining through dimension attribute value sets, and the general journal, inventory transactions, and sales line tables have semantics that take a functional consultant to explain. Data entities are shaped better but are not universally available in Synapse Link and carry their own quirks.

Budget for a Snowflake modelling layer, typically in dbt, that turns raw F&O tables into the ledger, inventory, and sales facts the business actually wants. The transport takes weeks; the modelling takes months, and it is the part that requires someone who understands F&O, not just SQL.

Incremental loads and deletes

Synapse Link produces change folders with insert, update, and delete markers. Your Snowflake load needs to apply deletes, not just append, or the warehouse will slowly diverge from F&O. Merge statements keyed on RecId per table are the standard approach. Test the delete path deliberately; it is the one people skip.

Security and residency

The lake account sits in your Azure subscription, so residency follows your storage region. Snowflake reads through a storage integration scoped to that container. Row-level security from F&O does not travel with the data; whatever access rules F&O enforced by legal entity or role need re-implementing in Snowflake. Financial data leaving F&O for a warehouse is a compliance conversation, not just an engineering one.

What breaks in practice

Schema changes. A new field on an F&O table appears in the lake; the Snowflake external table does not know about it until someone updates the definition. Automate schema drift detection or you will be surprised at quarter end.

Entity availability. Not every data entity is enabled for Synapse Link, and some require configuration on the F&O side. Confirm your list before promising the data team anything.

Latency expectations. "Near real time" from Synapse Link means minutes for tables and longer for entities. If someone wants a live inventory position, the warehouse is the wrong place to get it.

Stability verdict

The pipeline is stable once built: Microsoft export to a lake you own, Snowflake reading from that lake. The parts that move are Microsoft's export mechanisms, which have been reshuffled more than once, so keep the transport layer thin and replaceable. If you have a genuine choice of warehouse, Fabric with Dynamics 365 removes the transport step entirely, but nobody should switch warehouses to avoid one pipeline.