Grab a spot →
Skip to main content

Operating Power BI day to day

Connect docs via MCP

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).
  • 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.