## TL;DR
Check the user against the security roles on the dataset before changing the report. Row level security filters are defined on the semantic model, and a user who belongs to no role, or whose role rule excludes their rows, sees an error or an empty report while colleagues are unaffected. Add the user to the correct role, test the role in Desktop, and republish if the rules themselves changed.

```text
Power BI row level security breaks dashboard: user has no access error fix
```

## Use this when
- One user or one group cannot see data while other viewers use the same report normally.
- The affected user opens the report but gets an access style error or a blank page of visuals.
- Roles or the underlying user table changed recently, such as a team restructure.

## Not for this skill when
- No viewer can open the report at all. Check workspace access and dataset health first.
- The user sees data but the wrong rows. That is a rule logic problem to remodel, related but different from a no access break.

## Steps
1. Confirm the user can open the report shell and note the exact error or blank state they see. Verify: the failure is at the data layer, not at opening the report
2. Open the dataset security page in the service and review the role membership lists for the user or their group. Verify: the user is either missing from every role or present in a named role you can test
3. In Desktop, use the view as role feature to test each role the user belongs to, including any dynamic identity rule. Verify: the tested role reproduces the user experience
4. Correct the fault, adding the user or group to the right role in the service, or fixing the role rule and republishing the model. Verify: the security page shows the corrected membership, or the republished model carries the new rule
5. Have the affected user reload the report and confirm data appears for their scope. Verify: the user sees their expected rows and no access error
6. Review other members of the same team for the same missing membership so the fix is not repeated user by user. Verify: the team group, rather than individuals, is assigned where possible

## Why it happens
Row level security failures are per user by design, which makes them look like personal account problems until the pattern is seen across a team change. Assigning groups rather than individuals to roles, and testing roles after any user table change, keeps membership aligned with the organisation instead of with whoever reported the problem first.

Power BI row level security works in two halves. The rules and roles are authored in Desktop on the model, and the membership of each role is assigned in the service per dataset. Either half can be wrong independently, a correct rule with the user missing from the role, or a membership that exists against a rule that filters out the user rows. Dynamic rules based on the signed in identity add a third failure point when the identity value does not match the data.

Field notes for Power BI specifically. The refresh history on each dataset, the gateway cluster view in the admin portal, and the workspace activity log together answer most incident questions without opening Desktop. The service and Desktop also diverge in behaviour often enough that a Desktop pass should never close a service incident. Test as a viewer in the browser, in the workspace the audience actually uses, because premium capacity, workspace version, and app publication state all change what the audience experiences compared with the author view.

Power BI estates benefit from an ownership rule that survives staff changes, datasets owned by a team alias or a service account pattern the tenant supports, with a named human deputy. A large share of refresh and security incidents trace back to content owned by someone who left, changed role, or lost a licence. Auditing dataset owners quarterly, and moving orphaned production content before it breaks, prevents the class of failure where the fix is trivial but nobody left on the team has the rights to apply it.
## Variants and edge cases
### Power BI row level security user has no access fix roles
The role membership phrasing for the service side fix.
### Power BI RLS works for others one user blank report
The comparison phrasing that isolates the per user pattern.
### Power BI dynamic RLS identity mismatch userprincipalname
The dynamic rule variant where the identity value fails to match.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_kvCB4HQ8r0vcArpT580k1A