Microsoft Power BI connectivity errors
Errors that occur when connecting Atlan to Microsoft Power BI and running the crawler, what each means, and how to fix it.
Errors that occur in the field when connecting Atlan to Microsoft Power BI and running the crawler. For platform-side entries, there's nothing to fix in Azure or Power BI; contact Atlan support with the error signature.
Client secret expired
AADSTS7000222: client secret keys … are expired. Runs die in 1–2 minutes; crawler and miner fail together.
Cause
The Azure client secret reached its expiry date. The classic signature is "it failed suddenly and nothing changed"; the change was time.
Solution
- Azure portal → app registration → Certificates & secrets → New client secret.
- Copy the Value immediately (shown only once).
- Paste it into Atlan → Test Auth → re-run crawler, then miner.
- Update every workflow sharing the app registration and record the new expiry date.
Secret ID pasted instead of Value
AADSTS7000215: Invalid client secret provided
Cause
The Secret ID (a UUID) was pasted instead of the secret Value (the long random string). The secrets table shows both columns; Atlan needs the Value column.
Solution
Generate a fresh secret, copy the Value immediately (shown only once), and paste it into Atlan.
Client ID and Tenant ID don't match
Application with identifier '…' was not found in the directory
Cause
The Client ID and Tenant ID in Atlan don't belong to the same app registration. Usually the Tenant ID was copied from a different location instead of from the app registration's Overview page.
Solution
Copy both values from the same app registration Overview page.
401 PowerBINotAuthorizedException on metadata scan
401 PowerBINotAuthorizedException immediately after a successful Test Authentication.
Cause
Test Authentication only validates Layer 1 (Azure token issuance). This 401 means a Layer 2 door is closed: the "Service principals can access read-only admin APIs" tenant setting is off, or the service principal isn't a direct member of the security group the setting is scoped to. On trial Fabric tenants, the setting may not be visible at all.
Solution
- Fabric admin enables all four admin API tenant settings and scopes each to the security group.
- Verify the service principal is a direct member of the group (nested groups may not resolve).
- Wait 30 minutes for propagation before re-testing.
403 on workspace preflight or individual workspace
403 Forbidden on workspace access checks or preflight.
Cause
Either the "Service principals can call Fabric public APIs" tenant setting is off for the service principal, or the bare app registration identity was added to the workspace instead of the Enterprise Application object.
Solution
- Enable "Service principals can call Fabric public APIs" in Tenant settings, scoped to the security group.
- In workspace access, add the Enterprise Application object (search by the app name), not the app registration directly.
PowerBINotAuthorizedException on scanner API endpoints
PowerBINotAuthorizedException on scanner API calls despite correct credentials.
Cause
Scanner-only mode is enabled but the admin API tenant settings aren't. No workspace membership combined with no admin APIs means no data is accessible at all.
Solution
Enable all four tenant settings (see Configure tenant settings) or disable scanner-only mode.
Deletion circuit breaker fires
Delete percentage is more than 80.0. Exiting
Cause
The run deleted more than 80% of previously cataloged Power BI assets, so Atlan halted it. Nothing is deleted when the breaker fires; your catalog is intact.
Legitimate causes: narrowed Include Workspaces filter, revoked service principal workspace access, or workspace reorganization. A platform regression can also trigger this incorrectly.
Solution
Diagnose why the asset count shrank before overriding. If the deletion is intentional, contact Atlan support to lift the breaker for one run. If it fires with zero changes on your side, say exactly that when reporting it; it redirects the investigation to a potential Atlan-side regression. See Operating Power BI day to day for more on the circuit breaker.
Referenced entity not found at publish (ATLAS-404)
ATLAS-404-00-00A: Referenced entity … not found during the publish stage.
Cause
Lineage records reference assets that aren't in the catalog yet. Usually the upstream source crawler (Snowflake, Oracle, or similar) hasn't published its assets yet, or the crawler failed partway through.
Solution
Re-run the crawler once. Ordering issues self-heal because the missing parent assets are created by the failed run. If the same count appears on every run, raise it to Atlan support. Make sure source crawlers run before the Power BI crawler.
Not authorized to update or create entity (ATLAS-403)
ATLAS-403-00-001: … not authorized to perform update/create entity
Cause
The Atlan-side identity running the workflow doesn't have catalog permissions: the manual runner isn't a connection admin, the workflow owner was demoted to Guest, or a tag-based Deny purpose policy is blocking specific assets. One denied asset fails the entire run.
Solution
Re-run as a connection admin, restore the owner's role, or review Deny policies on tagged assets.
Workflow fails with userEnabled false
Workflow fails with userEnabled: false in publish checks despite valid credentials.
Cause
The workflow's creator was offboarded and their Atlan account disabled. Workflows impersonate their creator at the publish stage.
Solution
Contact Atlan support to transfer workflow ownership. Ask them to move schedules too, not just ownership. Prevent this by using a service account as the workflow owner.
404 EntityNotFound for individual reports in logs
404 EntityNotFound or ItemNotFound for a small number of reports in run logs.
Cause
Reports were deleted or moved in Power BI since the last crawl. The connector skips them and continues.
Solution
Isolated 404s: ignore. If the count is large, or every report fails, it isn't deletions, see the next entry.
No column or measure lineage, and report definitions 404 for every report
Column and measure to page lineage is empty after a successful run. Logs show fetch_report_definitions: 0/<N> definitions written and a 404 EntityNotFound per report:
Report definition start failed (404) for report <report-id> in ws <workspace-id>:
{"errorCode":"EntityNotFound","message":"The requested resource could not be found","isRetriable":false}
The run itself succeeds and every other Power BI asset extracts normally.
Cause
Report definitions are read from a different Microsoft API than the rest of the extraction: the Fabric API Get Report Definition at api.fabric.microsoft.com, not api.powerbi.com. It has prerequisites of its own, so the rest of the crawl succeeding says nothing about it. Fabric returns 404 both for a report that doesn't exist and for one the caller isn't allowed to read, so 404s on every report point at a missing prerequisite rather than at deletions.
Solution
Start on the Atlan connection: Enable Scanner APIs Only Access must be off, and Fetch Report Definition Extracts must be on, which is the default.
The same requirements gate Fetch Extracts for Context Agents, which reads semantic model definitions through the Fabric API as well. With that toggle on, a credential that's refused for every report and semantic model fails the run with PERMISSION_DENIED_DEFINITION_API instead of succeeding with no lineage. Fix the requirements below, or turn the toggle off, then re-run.
Then check the three Microsoft-side requirements, in this order. Atlan's preflight checks validate none of them:
- Contributor or higher on the workspaces. Get Report Definition needs read and write on the report, so a Viewer role fails it even with every tenant setting enabled. Check this first, because every other part of the connection works without it. See Configure tenant settings.
- The
Service principals can call Fabric public APIstenant setting, scoped to a security group the service principal is a direct member of. Allow 15-30 minutes for a change to propagate, then re-run. - No encrypted sensitivity labels on the reports. Microsoft blocks the API for those whatever the role.
A Report definition start failed line carrying no status code means the endpoint wasn't reached rather than refused: check that api.fabric.microsoft.com is allowed by any egress or private-link policy. If all three hold and definitions still 404, contact Atlan support with the workflow run ID and a sample log line.
InvalidObjectState at miner stage
InvalidObjectState during the miner stage.
Cause
An S3 lifecycle policy archived Atlan's workflow artifacts, such as activity events, to Glacier, which can't be read on demand.
Solution
Exclude Atlan workflow paths (for example atlan/workflows/*) from Glacier lifecycle transitions, then run the workflow again.
Source owner shows unexpected values or is missing
Source owner displays an email address instead of a username, shows an unexpected value, or is blank for some assets in the same workspace.
Cause
Atlan maps the source owner field directly from the Power BI API response. The API returns createdBy for reports and configuredBy for datasets and dataflows. It only returns email addresses, not usernames, for supported asset types. For other asset types the API returns null.
Solution
Source owner in Atlan reflects what Power BI APIs return; this is by design and can't be overridden.
Connector app is down
dial tcp … powerbi-app.svc.cluster.local … no such host
Cause
The connector app itself is down on your Atlan tenant. Requests never reach Microsoft. Re-entering credentials won't fix this.
Solution
Report to Atlan support and mention this exact error. Don't re-enter credentials; it's an infrastructure issue.
Tenant identifier shown as none (AADSTS900023)
AADSTS900023: tenant identifier 'none'
Cause
The connector app didn't receive your credential fields; this is an app-version bug, not a problem with your input. A direct token call to login.microsoftonline.com with the same values proves your credentials are correct.
Solution
Report to Atlan support; they sync the tenant's app image.
Workflow stuck in Running state for days
Workflow shows "Running" for days; scheduled runs produce no new runs.
Cause
A wedged run (caused by a deploy-during-run race or engine migration) is blocking the schedule. Long Publish steps with blank logs may also be genuinely large publishes; compare to your typical runtime before escalating.
Solution
Ask Atlan support to check backend state, terminate the stuck run, and re-trigger. Extracted data is preserved.
Exit 143 or pod deleted after hours
Exit 143 or "pod deleted" after hours; retries start on different nodes; manual reruns succeed but scheduled runs fail.
Cause
Infrastructure node reclamation kills long-running pods. The timing-dependent pattern explains why manual reruns succeed but scheduled runs fail.
Solution
Report the pattern to Atlan support. The fix (on-demand node routing) is Atlan-side.
TIMED_OUT on large estates
TIMED_OUT after 24–72 hours on large tenants.
Cause
Throughput, not breakage. Millions of entities exceed default publish deadlines. This is common after long idle gaps that force a full re-publish.
Solution
Contact Atlan support to raise timeouts and scale resources. Prevent recurrence by keeping schedules regular and scoping with workspace filters.
Failed to load failure logs
"Failed to load failure logs" shown in the Atlan UI.
Cause
A UI rendering limit caused by oversized log lines. The logs exist in backend storage.
Solution
Provide Atlan support with the workflow ID, run URL, and timestamp; they can retrieve the full logs.
500 errors during setup on new tenants
500 errors during initial setup with preflight checks passing.
Cause
Incomplete tenant provisioning. Nothing you configured is wrong.
Solution
Escalate to Atlan support immediately, especially on POV tenants.