Microsoft Dataverse to Snowflake: How to Move Your Data

Replicating Microsoft Dataverse to Snowflake takes the data behind Dynamics 365 and your Power Platform apps and puts it where the rest of the business reports from. Sales, service, and custom app records stop being a separate island and start joining against finance, product, and marketing tables.

One setting decides whether this pipeline is efficient or brutally wasteful, and it is not in Airbyte. It is a per-table toggle in Power Apps that most people do not know exists.

Why does change tracking decide everything?

The Microsoft Dataverse source reads through the Dataverse Web API and automatically discovers every table in your environment using the EntityDefinitions endpoint. Each table becomes a stream, which makes setup feel effortless.

Incremental sync works differently from a database cursor. The connector sends a change tracking request header, and Dataverse returns a delta link on the final page of results. Airbyte stores that link as state and uses it next sync to fetch only what changed. It is elegant, and it depends entirely on change tracking being switched on.

Change tracking is enabled per table, in Power Apps table settings, and it is not on by default. Tables without it support full refresh only. Nothing in Airbyte warns you. You can select twenty tables, schedule an hourly sync, and quietly re-read your entire Dataverse environment every hour because nobody enabled tracking table by table.

Audit this before your first run. Enable change tracking on every table you intend to sync incrementally, and treat any table where you cannot enable it as a deliberate full-refresh candidate with a frequency to match.

That matters more here than with most sources because Dataverse enforces service protection limits and returns HTTP 429 when you exceed them. Full refreshes on large tables burn through those limits fast, so an unnecessarily aggressive schedule does not just waste time, it can get your syncs throttled.

How do Dataverse types map to Snowflake?

The connector uses v9.2 of the Web API and maps Dataverse types as follows. Two rows in this table deserve more attention than the rest.

The Money row is the one that will cost you. Dataverse Money fields hold opportunity values, invoice totals, and pricing, and they arrive as the Airbyte number type. Snowflake's Decimal Data Type option defaults to FLOAT, an approximate binary floating-point type. Your CRM revenue figures would land as approximations, and the discrepancies will be small enough to escape notice and large enough to embarrass someone in a board deck.

Set the Decimal Data Type to NUMBER(38,9) before the first sync. Changing it later makes Airbyte convert existing columns in place, which can null or truncate values, so this is a decision to get right up front rather than fix.

The Status and State row is worth a note too. Those arrive as integer option set codes rather than the labels users see in Dynamics, so anyone querying the warehouse will need a lookup to turn a status of 1 into something a human recognises.

How do you set up the pipeline?

On the Dataverse side you need your environment URL and credentials for an application registered in Entra ID with access to the environment. The connector discovers tables automatically once connected, so there is no stream list to maintain by hand.

On the Snowflake side, run the setup script in the destination docs from a worksheet with the ACCOUNTADMIN role. It creates a dedicated role, user, warehouse, database, and schema, provisioning an X-Small warehouse with a 60-second auto-suspend. Snowflake bills compute per second and resumes on every load, so that sizing matters more than raw power for a scheduled pipeline like this.

Key pair authentication is stronger than a password. If a network policy is set on your Snowflake account, add the Airbyte Cloud IP addresses to the allowlist. Then select your tables, choose incremental where change tracking is enabled, and set a frequency your service protection limits can absorb.

What happens when records are deleted?

The connector supports CDC and replicates incremental deletes, but with an important caveat: not all entities support it, and deleted records only carry the ID.

In practice that means Snowflake learns a record disappeared but not what it contained at the time. If you need to know the value of a deleted opportunity, capture that history yourself with a slowly changing dimension pattern downstream rather than expecting the delete event to carry it.

Frequently asked questions

Why are my syncs doing full refreshes every time?

Change tracking is almost certainly disabled on those tables. It is a per-table setting in Power Apps and it is off by default. Without it, incremental sync is unavailable and the connector re-reads everything.

Should I change the Snowflake number type?

Yes, if you are syncing Money fields, which most Dataverse environments are. Set NUMBER(38,9) before the first sync so revenue and pricing figures stay exact rather than becoming approximate floats.

Why am I getting HTTP 429 errors?

Dataverse enforces service protection limits. Reduce sync frequency, enable change tracking so you are pulling deltas rather than whole tables, and deselect tables you do not actually need.

Why are some fields missing from my schema?

Virtual fields are excluded from the schema and never synced. If a calculated or virtual column matters to your reporting, reproduce that logic in Snowflake instead.

Do I get the full record when something is deleted?

No. Deleted records carry only the ID, and not every entity supports delete replication. Keep your own history downstream if the contents of deleted records matter.

Get your Dataverse data into Snowflake

Enable change tracking table by table, set the exact number type before the first sync, and pace your schedule against Dataverse's service limits. Consolidating onto a lakehouse instead? See our guide to Microsoft Dataverse to Databricks. Replicating a database into the same warehouse? See PostgreSQL to Snowflake.

Start syncing now →