Dashboarding — Troubleshooting
A dashboard was built and launched, but nobody actually uses it
This is rarely a technical problem — it almost always traces back to skipping the "define the question" step from the Fundamentals tab. A dashboard built from available data rather than an actual stakeholder decision often shows technically correct numbers that don't map to how anyone actually makes a decision day-to-day — the fix isn't a visual redesign, it's going back to the actual intended user and asking specifically what decision they need to make and what's currently blocking that decision, then rebuilding around that answer. A quick, honest signal worth checking directly: ask the dashboard's intended primary user to describe, unprompted, what decision it helps them make — if they can't answer clearly, the dashboard was likely built data-first rather than question-first, and that's the root cause worth fixing before investing in polish.
A DAX measure returns wrong or unexpected numbers for some date ranges
This is very often the dedicated date table issue covered on the Intermediate tab — a raw fact-table date column has gaps on days with zero transactions, which silently breaks time-intelligence functions (SAMEPERIODLASTYEAR, TOTALYTD) that assume a continuous date sequence. Confirm a proper Date Table exists, is marked as a Date Table in the model, and that every relevant time-intelligence measure references it rather than a raw fact-table date column — this specific bug is genuinely common because it works correctly for date ranges with no gaps and only surfaces for the specific ranges that happen to include one, making it easy to miss during initial testing against a "normal" recent date range.
A dashboard is technically correct but stakeholders don't trust the numbers
A trust gap is often not about accuracy at all — it's about a mismatch between the dashboard's number and a number the stakeholder already has from another source (an export they built manually, a different report, a gut sense of the right magnitude), with no visible explanation for the discrepancy. The fix is making the dashboard's data lineage and refresh timing explicit and visible — a visible "last refreshed" timestamp, and, ideally, a documented definition of exactly what each metric includes/excludes (does "Revenue" include tax, refunds, a specific product line) — since an unexplained discrepancy erodes trust in every number on the dashboard, not just the one that actually differs, even when the dashboard's number is the correct one.
Row-level security isn't filtering data correctly for a specific user
If RLS isn't producing the expected filtered view for a user, the most common causes are: the security role's DAX filter expression referencing the wrong identity field (mismatched between USERPRINCIPALNAME()'s actual returned format and how the user identity is stored in the mapping table — a case-sensitivity or domain-suffix mismatch is a common specific culprit), the user not actually being assigned to the intended role in the Power BI Service (a configuration step separate from writing the DAX filter expression itself), or — a subtler cause — a relationship in the data model that doesn't propagate the filter correctly across all the tables a report visual actually draws from, leaving some visuals correctly filtered and others not. Testing RLS using the "View As Roles" feature during development, for a specific test user in each role, before publishing is what catches this before a real user reports seeing data they shouldn't (or, just as commonly, data unexpectedly missing).
A previously-fast dashboard has become noticeably slower over time, with no obvious change
The most common real cause is data volume growth outpacing the original data model design — a fact table that was small enough for a full extract refresh to be fast six months ago may have grown enough that the same full-refresh approach now takes meaningfully longer, and incremental refresh (covered on the Advanced tab) that wasn't necessary at launch has quietly become necessary as the table grew. Checking actual refresh duration trend over time (not just current absolute time) is what reveals this as a gradual capacity issue rather than a single specific misconfiguration — the fix is the same architectural change (incremental refresh, or reviewing DirectQuery vs. import mode) regardless of when the threshold was crossed, but recognizing "we've simply outgrown the original design" as the actual cause, rather than searching for a recent breaking change that doesn't exist, is the first step.