Row level security, can group membership overrule rowlevel filter?

Hii CaptainData 

A Member role in the report workspace does not override RLS if the report uses a semantic model from another workspace. RLS is evaluated against the workspace containing the semantic model. If User A is only a Viewer there, the filter still applies. If the semantic model is in Workspace 2 and User A is truly a Member there, RLS should not apply check the report lineage and the user’s effective access to the semantic model workspace.

The link below clearly explains this:

https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security 

Building on rohit1991's answer — which is the right diagnosis — here's how to confirm it and close it in your case, because your two-workspace symptom is the fingerprint of exactly this.

Why it happens: RLS is only enforced on people who reach the model as *Viewers*. Anyone with Member/Contributor/Admin on the workspace that holds the semantic model (or with Build permission granted directly on the dataset) is treated as a data owner, so RLS is skipped entirely. That's precisely your split — Workspace 1 the person is a Viewer (filter applies), Workspace 2 they're a Member (filter bypassed). Nothing wrong with your role definition; it's the workspace permission overruling it.

Two-minute confirmation: open the semantic model → Security → the three dots on the role → "Test as role". Add the user together with the role. If the data looks correct there but wrong in the live report, it's an access-level bypass, not a DAX problem.

The fix, in order of preference:
1. Don't put consumers in the model's workspace as Members. Give report access through an App or a Viewer-level share, and keep Member/Contributor for the people who actually build.
2. If User A genuinely needs Member rights for other reasons, separate the roles: report consumers go in a security group that only ever gets Viewer/App access; builders are a different group.
3. Broader pattern: split the semantic model into its own workspace from the reports, so "who can edit" and "who can read filtered data" stop being the same switch.

RLS can't be enforced on someone the platform considers an owner of the data — so the real fix is always at the access layer, not in the role's DAX.

RLS is only decided in the workspace that holds the semantic model, and Viewer there is always filtered. open Lineage, find the model, and set your role in that workspace to Member — RLS never comes from the report workspace.