Desktop success, service staleness or access denial

Understand the likely causes

• Possible causes include an old import copy, stale upstream data, a broken service source/gateway mapping, failed transformation, missing permission, unsupported license/capacity entitlement or a different RLS population.

Classify the failing boundary

Record exact model/report identity, consumer identity category, symptom and time without exporting personal identifiers or secrets. Determine whether the report opens, whether it queries the intended model and whether the problem is old data, denied access or entitlement. Desktop success establishes an author-machine path, not the service’s path or the consumer’s rights. A license prompt does not imply a broken DAX expression, and an old total does not automatically imply a permission problem. Preserve these distinctions before changing a shared artifact, because a broad role grant can alter security without fixing freshness.

Trace data cutoff and refresh stage

For stale values, identify storage mode, latest completed processing, latest usable source data and reconciliation counts. A successful10:00 refresh can contain09:30 data, yielding45minutes of data age at10:15. Review approved source/gateway mapping and the exact failure stage if processing failed. An expired credential differs from a renamed-column transformation failure. The following record is synthetic and contains no service logs. Do not disable privacy, expose tokens or repeatedly trigger source work merely to obtain a green status; ask the responsible owner for the narrow evidence needed to resolve the stage.

observation:10:15 UTC
last processing completed:10:00 UTC
latest usable data:09:30 UTC
data-age claim:45minutes
separate access checks: permission + entitlement + applicable RLS population

Review access with the intended consumer

For denial, check the approved distribution path, granted permissions and current license/capacity requirements separately. A suitable license does not grant access, and permission does not guarantee entitlement. For differing permitted totals, review RLS role membership and the expected population. Workspace editing roles and Viewer do not have identical RLS behavior. App audience visibility is not a replacement for semantic-model security or alternate-path review. Correct the governed source of the mismatch instead of granting Contributor merely to make a test pass. Keep real membership and credential changes within the authorized owner’s workflow.

Verify one correction at a time

Define expected usable-data cutoff, row coverage, allowed totals and consumer outcome before the correction. After an authorized change, verify the relevant stage and the end-user result while retaining the original evidence. This guide performs no refresh, publication, sign-in, permission update or external message. Official licensing and gateway references identify current decision boundaries rather than prices or a tested tenant configuration. The editorial handoff is complete when it names the cause, contextual correction, verification requirement and remaining uncertainty; it must not claim that an offline explanation has already repaired or secured a service.

Keep it from recurring

• Maintain ownership for models, refresh connections and distribution; expose a defined data cutoff; keep Viewer/RLS and entitlement cases; and review schema and license/capacity assumptions before releases. Use synthetic evidence in public diagnostics.