Power BI troubleshooting is most effective when the analyst identifies the first layer where actual behavior differs from the design. A wrong chart can be caused by source data, Power Query, relationships, DAX, visual filters, refresh, workspace permissions, or row-level security. Randomly rewriting measures can hide the real problem.
The current PL-300 objectives explicitly include import errors, Performance Analyzer, DAX query view, refresh, gateways, workspaces, access, and security. That makes evidence-led troubleshooting part of exam readiness, not an optional support skill.
If data is missing before modeling, start with source and Power Query
Check credentials, privacy settings, parameters, source availability, query filters, errors, and load configuration. If a row is removed in Power Query, no measure can bring it back later.
The Power Query editor provides the earliest useful evidence for shaping problems. Confirm the expected row count and schema before debugging the semantic model.
If relationships behave strangely, verify keys and grain
Check cardinality, uniqueness, cross-filter direction, active versus inactive relationships, and role-playing dimensions. Duplicate dimension keys can invalidate a one-to-many design, while many-to-many relationships can create ambiguous results if used carelessly.
Use a data-modeling perspective before adding DAX exceptions. A stable model reduces downstream complexity.
If a measure is wrong only under certain filters, inspect context
Place simpler base measures in a table and add filters one at a time. Use DAX query view where helpful to understand the query context and evaluate CALCULATE logic.
The DAX troubleshooting question is usually “what filter context is active?” before “which function should I add?”
If a visual is slow, isolate the visual and measure workload
Use Performance Analyzer to identify which visual consumes time. Determine whether the delay comes from DAX, model relationships, source queries, or the number of visuals on the page.
Remove unnecessary fields or visuals, reduce model granularity, and simplify measures based on evidence. Performance should improve because the responsible layer changed, not because the page was randomly rearranged.
If the report is correct in Desktop but different in the service, compare environment state
Check published versions, workspace item, semantic model, credentials, gateway mapping, refresh status, permissions, and app update state. A stale published report can behave differently from the local file even when the author thinks both are “the same report.”
Deployment state belongs in the investigation. Republishing should be a deliberate fix, not the default first step.
If refresh fails, classify the failure before changing the model
Credential expiration, unavailable gateway, changed source schema, privacy rules, query errors, and source throttling create different refresh failures. Review refresh history and error details.
If an on-premises gateway is required, confirm that the correct data source is configured and reachable. A model change will not fix a gateway process that is offline.
If one user sees different data, check security and filter state
Compare row-level security role membership, identity, workspace role, semantic-model access, and report filters. Personalized visuals or persistent filters can also change the user experience without changing the underlying model.
Test RLS with representative user identities and verify the expected rows. Do not grant broader workspace access simply to bypass a model-level security problem.
If Copilot-generated content is misleading, validate the model and page context
Check the trusted measures, current filters, semantic-model descriptions, and prompt. A narrative can summarize the context it receives; it cannot repair a wrong business definition.
Analysts remain accountable for generated content. Correct the earliest responsible layer and then regenerate if appropriate.
If users misunderstand the report, treat usability as a defect
Review visual choice, titles, bookmarks, navigation, sync slicers, drillthrough, sorting, mobile layout, accessibility, and tooltips. A user who cannot tell which filters are active may make a wrong decision even when the calculations are perfect.
A Power BI visualization review can help distinguish a data problem from a communication problem.
Close every incident with a durable correction
After fixing the immediate issue, ask whether the model, query, workspace process, gateway monitoring, RLS documentation, or report design should change to prevent recurrence. Record the root cause in one sentence.
If a merge creates unexpectedly more rows, inspect the join keys and cardinality in Power Query. A many-to-many join at the query layer can multiply records before the model ever sees them. Compare row counts before and after the merge and validate key uniqueness. Fixing the resulting totals in DAX would only conceal the duplication.
If a date measure returns blanks for some periods, verify that the date table covers the full range, relationships are active as expected, and date columns use appropriate types. Time-intelligence functions assume a coherent date model. A calculation can be correct syntactically while the calendar structure is incomplete.
If a report app does not show the newly published page, confirm that the app itself was updated after workspace changes. Publishing to the workspace and updating the distributed app are distinct lifecycle steps. Consumers may still be seeing the previous app version.
If refresh duration increases suddenly, compare source volume, transformation changes, query folding, gateway performance, and model size. A newly added non-folding step or large detailed table can increase refresh work significantly. The best correction follows the change that explains the timing.
If RLS works in Desktop testing but not for a service user, check role assignment or group membership in the service and the user’s access path. The model rule and service identity mapping must both be correct. Workspace roles can also affect how RLS is experienced by authors versus viewers.
If a visual shows the right total but an incorrect breakdown, inspect grain and relationships before changing the measure. Totals can sometimes appear plausible even when category-level propagation is wrong. Use a simple matrix to expose which dimension values are reaching the fact table.
If a report becomes cluttered after users personalize visuals, remember that personalization is intentional self-service behavior. The support question is whether the base report and allowed personalization meet governance needs, not whether every user’s layout matches the author’s original design.
If Copilot cannot answer useful questions about the model, improve semantic clarity before assuming the feature is broken. Table names, measure names, descriptions, relationships, and trusted definitions all shape how users and AI-assisted experiences interpret the model.
If users export sensitive detail that was intended only for aggregated viewing, review export settings, underlying data access, semantic-model permissions, and the business requirement. Visual design alone is not a security boundary.
After each incident, document the earliest failed layer and the verification used after the fix. That creates a troubleshooting playbook that is far more useful than a list of error messages because the same architecture patterns recur across many datasets.
If a report suddenly uses more memory after a new feature, inspect calculated columns, imported detail, duplicated queries, and new tables before assuming the service capacity is the only problem. Model growth usually has a concrete cause. Remove unnecessary stored data or simplify the design where the business requirement allows it.
If users report that drillthrough opens the wrong context, inspect drillthrough fields, filter propagation, and button configuration. Navigation can preserve or override filters in ways that change the destination page. The model may be correct while the report interaction is misconfigured.
If a subscription sends stale values, compare the report refresh schedule with the subscription timing. A notification can execute successfully against data that has not refreshed yet. Operational scheduling should align data readiness with distribution.
If a workspace role change does not produce the expected RLS behavior, remember that content authors with elevated workspace roles can experience model security differently from ordinary viewers. Test with an identity that matches the intended consumer access path.
If an app consumer cannot see newly certified content, check whether the item is included in the app and whether the app was updated. Endorsement, workspace publication, and app distribution are related but distinct states.
If a semantic model refresh succeeds but a visual shows blanks, the source pipeline is probably not the first suspect. Check relationships, measures, filters, and visual field selection. Successful refresh proves data loaded, not that the report logic is correct.
If a user can open a report but cannot build from its semantic model, inspect build permission rather than row-level security. Viewing and creating new reports from a model are different capabilities and should be granted separately.
If a page becomes slow after adding automatic page refresh, confirm the connection mode, interval, number of visuals, and source capacity. Frequent refresh can multiply query load. The correct interval balances operational freshness with system cost.
If sensitivity labels do not prevent an action the organization wants to block, verify whether a separate permission or tenant policy controls that action. Labels communicate and integrate with governance, but they do not replace every enforcement mechanism.
When the root cause is fixed, document one preventive control: data-quality check, model test, refresh alert, gateway monitoring, measure validation, role review, or report-design standard. Troubleshooting should improve the analytical system, not simply restore one page.
If a certified semantic model is correct but a downstream report shows a different metric definition, check whether the report author created a local measure that overrides or duplicates the shared logic. Governance is not only about permissions; it is also about keeping business definitions consistent across reusable analytical assets.
Use one final rule during support work: reproduce the issue with the same user, filters, refresh state, and distribution path. Changing context before confirming the symptom can make the problem disappear without revealing the cause.
That preserves the evidence chain.
The wider PL-300 role is about reliable self-service analytics. Troubleshooting is complete when the original business question works again for the intended user under the intended refresh and security conditions.