Skip to content

Data-Source Lineage

This feature is supported only in the self-hosted product (Azure deployment). It is not available in BI Pixie Cloud or the Fabric Workload.

Data Sources: Power BI Admin Scanner API + BI Pixie Desktop (bi-pixie.exe)

Data-source lineage maps every workspace, semantic model, and dataflow in your tenant to its underlying connector, such as Databricks, Snowflake, SQL Server, SharePoint, or ADLS, and joins that map to real usage. The result is a filterable view that answers questions like: "show me every report connected to the platform we are retiring, and how much each one is actually used."

Why data-source lineage matters for migrations

A data estate migration starts with triage: which of your reports genuinely depend on the source platform, and which of those are worth re-platforming at all. Lineage, built from the Scanner API's connector details, answers the first question. BI Pixie answers the second from its engagement telemetry, with adoption (MAU, DAU/MAU), engagement (sessions, interactions), and satisfaction (CSAT, NPS) per report. Together they replace a discovery workshop with a filterable dashboard.

The composite score in the data-source lineage view measures engagement efficiency: consumer activity relative to producer effort and adoption. It is not a financial ROI figure, and we recommend not presenting it as one.

How data-source lineage works

The pbi_scan timer function in your BI Pixie function app calls the Power BI Admin Scanner API with datasourceDetails enabled, collects the scan results incrementally (only workspaces modified since the previous run), and stores them in your BI Pixie storage account. The BI Pixie Tenant Scans notebook then resolves each item's connector and joins it to the usage semantic model.

Permissions

The Scanner API is a read-only Power BI admin API, so your tenant must allow the function app's managed identity to call it:

  1. Create (or reuse) an Entra security group and add the BI Pixie function app's managed identity to it.
  2. In the Fabric admin portal, under Tenant settings, enable Service principals can access read-only admin APIs and scope it to that security group.
  3. Optionally enable Enhance admin APIs responses with detailed metadata so the scan carries table and column detail.

No workspace-level permissions are needed. The Scanner API reads metadata: items, connectors, schemas, expressions and access lists. It does not read report data.

Schedule and scope
  • The collection schedule is controlled by the PBI_SCAN_SCHEDULE environment variable on the function app (NCRONTAB format, same as the performance collector).
  • To limit the scan to specific workspaces, set the PBI_WORKSPACE_IDS variable with comma-separated workspace IDs. By default, every active shared workspace is scanned.
Where to find data-source lineage in the dashboard

Once scans are collected, you find the lineage view on the Endorsement & Data Sources page. It is available in 0. Master Report and in 4. Business Outcomes. Filter by connector to see every semantic model and report bound to a given platform, alongside how much each is used and by whom. BI Pixie collects viewer user names only when include_user is true in bi_pixie_config.json, and it then keeps the email address, or a masked ID when MASK_USER_NAME is true on the function app. When include_user is false, it counts viewers by a masked IP address.

Typical questions that data-source lineage answers
  • Which reports and semantic models are connected to the platform we are migrating away from?
  • Of those, which are actively used, and which can be retired instead of re-platformed?
  • Which workspaces mix connectors, and where does a single dataflow fan out into many reports?
  • After the migration, is anything still reading from the old source?

What's Next

Capture a performance baseline before a migration

Dashboard walkthrough