Area: Ingestion Issues
Sub-Area: Power BI Connector – Permissions & Authentication
Issue
When running a Power BI ingestion in DataHub, workspace content such as reports and dashboards may be successfully pulled, but lineage information does not appear in the UI. In the ingestion logs, HTTP 403 warnings are emitted for every workspace scan attempt, and the connector explicitly logs that it cannot access the Power BI Admin API. This occurs because the Azure Active Directory (AAD) service principal used for ingestion lacks the tenant-level permissions required to call the Power BI Admin (workspace scan) APIs, which are mandatory for extracting dataset lineage, cross-workspace relationships, endorsements, and Fabric artifact metadata.
Error Messages
WARNING - Unable to fetch get scan result.WARNING - HTTP status-code = 403WARNING - Dataset lineage can not be ingestion because this user does not have access to the PowerBI Admin API.WARNING - Incomplete Scan Metadata: Scan returned no metadata for this workspace; it will be ingested without scan-derived metadata (endorsements, app, fabric artifacts, cross-workspace dataset lineage). Check logs for any underlying HTTP or scan error.
You Might Be Asking
- Why is my Power BI ingestion pulling reports but showing no lineage in DataHub?
- Why do I see HTTP 403 errors in the Power BI ingestion logs even though the connector appears to be working?
- What Power BI Admin API permissions are required for DataHub lineage extraction?
- My service principal has Power BI permissions configured — why is lineage still failing with 403?
Solution
The Power BI connector uses the Power BI Admin workspace scan API to extract lineage. Standard workspace-level permissions are sufficient to read reports and dashboards, but Admin API access is required for lineage. Follow the steps below to grant the correct permissions.
-
Create or identify an AAD security group for your service principal.
Power BI Admin API access must be granted to a security group, not directly to a service principal. Ensure your AAD app registration (service principal) is a member of a dedicated security group in Azure Active Directory before proceeding.
-
Enable Admin API access in the Power BI Admin Portal.
Log in to the Power BI Admin Portal as a Power BI tenant administrator and navigate to Tenant settings → Developer settings. Enable the following setting and add your security group to the allowed list:
Allow service principals to use read-only Power BI admin APIs → Enabled → Specific security groups: <your-service-principal-security-group> -
Enable enhanced Admin API metadata settings.
Still in the Power BI Admin Portal, navigate to Tenant settings → Admin API settings and enable the following two options (also scoped to your security group):
Enhance admin APIs responses with detailed metadata → Enabled → Specific security groups: <your-service-principal-security-group> Enhance admin APIs responses with DAX and mashup expressions → Enabled → Specific security groups: <your-service-principal-security-group>The second setting is required if you want query-level (DAX/M expression) lineage in addition to dataset-level lineage.
-
Remove conflicting application-level Power BI Service permissions (if present).
Do not grant admin-consented Power BI Service application permissions such as
Tenant.Read.AllorTenant.ReadWrite.Allto your app registration in the Azure portal. These permissions can conflict with the Admin Portal security group allowlist and cause 403 errors even when the tenant settings appear correct. Remove any such permissions if they exist. -
Verify the DataHub ingestion recipe references the correct service principal credentials.
Confirm your ingestion recipe is using the client ID and client secret of the same app registration that belongs to the security group configured above:
source: type: powerbi config: tenant_id: "<your-azure-tenant-id>" client_id: "<your-app-registration-client-id>" client_secret: "<your-app-registration-client-secret>" # Additional config... extract_lineage: true admin_apis_only: false -
Wait for AAD permission propagation, then re-run ingestion.
Azure Active Directory and Power BI tenant setting changes can take several minutes to propagate. After waiting, trigger a new ingestion run and confirm that the HTTP 403 warnings are no longer present in the logs and that lineage is appearing in the DataHub UI.
Additional Notes
- Permission propagation delay is expected behavior in Azure AD. If the 403 persists immediately after making changes, wait 15–30 minutes before re-running ingestion before concluding there is still a configuration problem.
- Without Admin API access, DataHub's Power BI connector will still ingest basic workspace content (reports, dashboards, report pages) but will silently skip lineage, endorsements, cross-workspace dataset relationships, and Fabric artifact metadata. No ingestion failure is raised — only warnings in the logs.
- The service principal must be a member of an AAD security group that is explicitly added to the Power BI Admin Portal tenant settings. Adding the service principal directly (not via a group) is not supported by the Power BI Admin Portal allowlist mechanism.
- These requirements apply to both DataHub Cloud (managed) and self-hosted DataHub deployments. The Azure/Power BI configuration steps are identical in both cases.
- This behavior has been observed across multiple DataHub Power BI connector versions. Refer to the DataHub Power BI source documentation for the current list of metadata extracted with and without Admin API access.
Related Documentation
- Power BI Connector – Prerequisites & Admin API Access
- Power BI Connector – Capabilities (metadata extracted with/without Admin API)
- Power BI Connector – Admin APIs Ingestion Configuration
Tags: power-bi, lineage, ingestion, http-403, admin-api, service-principal, azure-active-directory, permissions, workspace-scan, connector