## Operating Power BI day to day

URL: https://docs.atlan.com/apps/connectors/business-intelligence/microsoft-power-bi/best-practices/operating-microsoft-power-bi

> Six operating practices for a Power BI connection, drawn from real-world failure patterns, from secret rotation to the deletion circuit breaker and capacity impact.

Setup is a day; operations are forever. These practices come from real-world failure patterns; each one prevents a class of incident that actually happens.

## Sequence workflows correctly

Run order matters and getting it wrong produces confusing, delayed failures:

- Run the **crawler first**, then the miner. The miner diffs against the crawler's assets; a failing crawler makes the miner fail a day later with symptoms that look unrelated.
- **Don't overlap** their schedules on the same connection. Let one finish before the other starts.
- If you also crawl the sources behind Power BI (Snowflake, Databricks, SQL Server…), run those crawlers *before* Power BI so cross-system lineage can stitch. Missing upstream assets are a common cause of publish-stage 404s.

## Rotate client secrets before they expire

Client secrets have a fixed lifetime (typically 1–2 years). Expiry is the most common cause of a healthy connection suddenly failing, and it takes the crawler and miner down together.

- **At setup:** Record the expiry date and set a calendar reminder 2 weeks ahead.
- **When rotating:** Use the same app registration, paste the **Value** (not the Secret ID), verify the update saved (the field displays blank, which is normal), and update every workflow sharing the registration.

## Plan for deletion circuit breaker trips

If a run deletes more than **80%** of previously cataloged Power BI assets, Atlan halts the run. Nothing is deleted when it fires; your catalog is intact and no restore is needed.

The circuit breaker can't be overridden from workflow config; only Atlan support can lift it, deliberately, for one run.

**Legitimate triggers:** narrowed Include Workspaces, revoked service principal workspace access, workspace reorganization, or enabling incremental extraction. Tell support in advance when planning a large reorg.

**Illegitimate trigger:** a platform regression that marks everything as deleted. If the breaker fires with zero changes on your side, say exactly that when you report it; it redirects the investigation correctly.

A miner circuit-breaker trip often means the crawler broke first. Fix upstream; the miner follows.

## Account for incremental extraction limitations

Incremental extraction reduces crawl time but has sharp edges that produce silent gaps:

- **The first run after enabling is always a full crawl.** This is expected.
- **Newly granted workspaces are invisible to incremental runs.** Granting workspace access to the service principal doesn't set Microsoft's "modified" flag. After adding workspaces, run one full crawl (temporarily disable incremental), then re-enable.
- **The incremental marker must survive between runs.** S3 lifecycle policies that archive to Glacier break it (see [Connectivity errors](https://docs.atlan.com/llms/connectors/microsoft-power-bi/microsoft-power-bi-connectivity-errors/llms.txt)).
- **Expected gains depend on churn:** stable tenants ~60–70% faster; active tenants 20–30%; high-churn under 5%. Daily schedules are more efficient than weekly for incremental.

## Schedule crawls to minimize capacity impact

Metadata scans run against your Premium capacity. A full scan of hundreds of workspaces can push CU utilization past 100% and throttle report users.

Levers to reduce impact, in order:

1. **Workspace Include filters** (CU scales with workspaces scanned)
2. **Enable incremental extraction**
3. **Schedule runs during off-peak hours**

If capacity spikes persist with incremental enabled, report it to Atlan support with your Power BI audit-log evidence.

## Scope large estates with workspace filters

Tenants with thousands of workspaces or millions of columns hit walls that look like mysterious failures: runs dying at a consistent wall-clock time (external timeout), publish stages running 24 hours or more, or DAX parsing stalls.

- Use workspace allowlists to crawl what matters (top few hundred workspaces).
- Keep schedules regular. A year-long idle gap turns the next run into a maximum-scale full publish.
- Contact support about raised deadlines for genuinely large estates.

## Set up monitoring and catch silent failures

The worst incidents aren't dramatic errors; they're quiet ones: a workflow failing daily for months, or scheduled runs silently skipped behind a wedged run.

Minimum monitoring:

- Failure alerting configured on the workflow and **test-fired once.** A webhook that was never verified counts as no alerting.
- A weekly check of last-run status and runtime trend. Runtime creeping up predicts timeout failures before they happen.
- Offboarding checklist: "Did this person create any Atlan workflows?" Transfer ownership **and schedules** before their account is disabled.
- After any permission or filter change, watch the next run; that's when circuit breakers and visibility gaps surface.

---