How Atlan connects to Microsoft Power BI
Atlan never connects to your network. It talks to the same public Microsoft cloud APIs that the Power BI service itself runs on, outbound over HTTPS:
login.microsoftonline.com, where Atlan exchanges your app credentials for an access tokenapi.powerbi.com, where Atlan reads workspaces, reports, datasets, and lineage metadata
Because both endpoints are Microsoft-hosted and always reachable from Atlan, there is nothing to open on your firewall and no IP address to allowlist. All the setup work is about identity and permissions, not networking.
Exactly one thing: traffic flows from Atlan to Microsoft's cloud, never into your company network. If your security team asks what needs to be opened, the answer is: nothing. What they can review instead is the service principal's permissions (read-only metadata access).
Three teams involved
Setup crosses three teams. Most stalled setups are waiting on a person, not a system—understanding who owns each step before anything is configured is the single biggest time-saver.
| Step | Who | Typical time |
|---|---|---|
| Create app registration + client secret + security group | Azure / Entra ID admin | 15 minutes |
| Enable 4 tenant settings, scope to the security group | Power BI / Fabric admin | 10 minutes + 15-30 min propagation |
| Grant the security group access to workspaces | Power BI / Fabric admin | Varies by workspace count |
| Create the connection, run preflight checks, crawl | You, in Atlan | 30 minutes + crawl runtime |
| Lift circuit breakers, transfer workflow ownership, tune timeouts | Atlan support | On request |
The tenant settings in step 2 can only be seen and changed by a Fabric Administrator (Power BI Service Administrator). Workspace admins can't do it, and on trial/POV Fabric tenants there is often no one with the role at all. Identify this person before you begin—missing admin access is the most common reason a new setup stalls for weeks.
What Atlan needs from Azure
Five values come from the Azure app registration. Everything entered into Atlan's connection form traces back to one of these:
| Value | Where it comes from |
|---|---|
| Directory (tenant) ID | App registration → Overview page |
| Application (client) ID | App registration → Overview page, from the same registration as the tenant ID |
| Client secret value | Certificates & secrets → shown once at creation. Copy the Value column, never the Secret ID |
| Secret expiry date | Same page—record it and set a rotation reminder (see Operating it day to day) |
| Security group name | The Entra ID group that contains the service principal, used to scope every Power BI setting |
How these guides are organized
- The two permission layers: The mental model that explains 80% of failed setups—why "Test Authentication passed" doesn't mean it works.
- Set up Microsoft Entra ID: App registration, secret, security group, including the counter-intuitive "zero API permissions" rule.
- Configure Power BI tenant settings: The four independent toggles, the workspace role matrix, and the Scanner API trade-off.
- Connectivity errors: Every recurring error message, what it means, who fixes it, and how.