Overview

Power BI dataflows are reusable, cloud-hosted Power Query (M) transformations that run on a schedule to prepare data, which reports and semantic models then build on. Monte Carlo can ingest your dataflows so you can monitor them and see a dataflow's refresh history, whether its last refresh succeeded, get alerted when a refresh fails, and most importantly trace lineage through the dataflow so a report's dependency on an upstream warehouse table is seen.

The Dataflows integration is layered onto your existing Monte Carlo Power BI connection, reusing the same service principal and credentials end-to-end. No new connection or credentials are required, you enable dataflow collection on the Power BI integration you already have.

Feature Support

Dataflow generations

Power BI has three flavors of dataflow, and Monte Carlo discovers them from two different APIs:

A few things worth knowing:

• Gen1 and standard Gen2 are collected together via the Power BI admin API; CI/CD Gen2 is collected via the Fabric API.
• Gen2 dataflows can write to a data destination (a Lakehouse, Warehouse, Azure SQL table, etc.); Gen1 dataflows cannot — they persist to Power BI's internal storage and are consumed by semantic models. This difference is what drives the two lineage shapes below.
• If a service principal can't reach the Fabric API (for example, the Fabric tenant setting below is off), Monte Carlo still collects Gen1 and standard-Gen2 dataflows from the Power BI admin API — you simply won't get CI/CD Gen2 dataflows until Fabric access is granted.

What Monte Carlo Ingests

Dataflows

Each dataflow is collected as one asset. For each, Monte Carlo captures:

• Definition — the dataflow's Power Query (M) document and query metadata, used to derive lineage
• Transformation queries — the named queries the dataflow runs (destination-helper queries are excluded)
• Workspace — the Power BI workspace / Fabric workspace the dataflow belongs to

Refresh runs

Monte Carlo collects the dataflow's refresh (transaction) history: status (success, failed, cancelled, in progress, queued, skipped), start and completion times, and how the refresh was triggered (schedule, manual, or API).

Lineage

A dataflow sits between your source tables and the Power BI assets that consume it. Monte Carlo resolves lineage in two shapes, depending on how the dataflow is used:

1. Table → Table (Gen2 with a data destination)

When a Gen2 dataflow writes to a data destination that Monte Carlo already monitors (for example a Snowflake, BigQuery, Databricks, or Redshift table), Monte Carlo derives a source table → destination table edge and attributes it to the dataflow, so you can see the dataflow was the job that produced the destination table.

2. Table → semantic model → report (dataflow as a source)

When a dataflow (Gen1, or Gen2 without a monitored warehouse destination) is used as the source of a semantic model that in turn feeds a report, Monte Carlo folds the dataflow's resolved source tables into the semantic model's upstream tables, completing the chain source table → semantic model → report. This is what lets you trace a Power BI report all the way back to the warehouse table behind a Gen1 dataflow.

Key points for both shapes:

• A referenced table must be monitored by Monte Carlo for the edge to land on it.
• Table-level only. Column-level lineage is not produced.
• Lineage can take up to 24 hours to appear due to batching.

Prerequisites

• An existing Monte Carlo Power BI connection (see Power BI). Dataflow collection reuses that connection's service principal — you do not create a new one.
• The service principal permissions below.

Required permissions

Dataflow collection uses read-only APIs only. The service principal needs no additional Azure AD API permissions beyond what your Power BI connection already uses — access is governed by tenant settings and workspace membership, not by admin-consent API permissions.

For Gen1 and standard Gen2 (Power BI admin API) — already satisfied by your existing Power BI connection:

• The service principal must be in the security group enabled for "Allow service principals to use read-only Power BI admin APIs" in the Power BI/Fabric admin portal. This is the same setting your Power BI report collection already requires, and it covers dataflow discovery, definitions, and refresh history.

Additionally, for CI/CD Gen2 (Fabric API):

• Enable the "Service principals can call Fabric public APIs" tenant setting (Fabric admin portal → Developer settings), scoped to the same security group.
• The service principal needs access to the Fabric workspaces containing the dataflows — the same workspace membership you already grant it for report collection.

Setup

You enable Dataflows collection on your existing Power BI integration — it reuses the same connection and credentials.

Go to Integrations → Add → Orchestration → Power BI Dataflows, choose your existing Power BI integration, and confirm. Once enabled, Monte Carlo begins collecting dataflows and their refresh history on the regular collection schedule.

Real-Time Refresh Failure Alerts (Power Automate)

By default Monte Carlo collects refresh history on a polling schedule. If you want a failed refresh to surface in Monte Carlo within seconds to minutes instead of on the next collection cycle, you can have Power BI notify Monte Carlo the moment a refresh fails, using a Power Automate flow that calls Monte Carlo's collection webhook.

You create one flow per dataflow you want to monitor in near real time.

1. Get your Monte Carlo webhook URL and integration token

On the Power BI Dataflows setup page in Monte Carlo, copy your unique webhook URL and generate an integration key. Save the key's ID and secret — the flow sends them as the x-mcd-id and x-mcd-token headers.

2. Create the Power Automate flow

Create an automated cloud flow with the following:

Trigger — "When a dataflow refresh completes" (Power BI connector). Set its parameters to the group (workspace) and the dataflow you want to monitor.

Only run on failures. On the trigger, open Settings → Trigger conditions and add:

@equals(triggerOutputs()?['body/status'], 'Failed')

This makes the flow fire only when that dataflow's refresh fails, so you're not calling the webhook on every successful refresh.

Action — "HTTP" (premium). Configure it as:

The slice(...,0,36) trims the trigger's dataflowId to the 36-character dataflow GUID, which is exactly the job_source_id Monte Carlo uses to identify the dataflow. On failure, the webhook triggers an on-demand collection of that dataflow's latest refresh, and Monte Carlo raises the alert.

3. Save and turn the flow on

Save the flow and make sure it is enabled (turned on) — a saved-but-off flow won't send anything. Repeat for each dataflow you want covered in near real time.

FAQs

Q: My dataflows appear, but I don't see lineage.

• The source or destination table isn't monitored by Monte Carlo or we are having trouble parsing the Power Query (M) definition. Reach out to our Support team if you believe this is the case.

Q: I see Gen1 and Gen2 dataflows but not my Fabric (CI/CD) dataflows.

• The service principal can't reach the Fabric API. Enable the "Service principals can call Fabric public APIs" tenant setting and make sure the service principal has access to those Fabric workspaces. Gen1/standard-Gen2 collection is unaffected.

Q: A refresh failed but Monte Carlo doesn't show why.

• For Gen1 and standard-Gen2 dataflows, Power BI's admin refresh API doesn't return a failure reason. Open the dataflow's Refresh history in the Power BI service (or Fabric portal) for the detailed error.