You don't have access because row level security (RLS) was applied

[Tas]

I have a model and report developed in PBI Desktop, with Roles and RLS applied.  Some roles do NOT have any filters specified.  When I test the roles in desktop they respond as expected.   

The model is deployed to a MIS Dev group, where dashboards are created, and from there the model, reports and dashboards are deployed to an End User group using a content pack.  When a user that is a member of the End User group views dashboards the get the "You don't have access because row level security (RLS) was applied" message on all elements of the dashboad.  On reports the get an error on each visual, which say there is a problem accessing data.

Question is: should RLS work on DBs and Reports that are deployed by Content Pack?  If so what specifically is required to make this work (eg should the members be in both the end user groups and the dev groups etc).

[v-sihou-msft · Accepted solution]

@Tas

Based on your error message, it means your end users are not added into the a security role under the corresponding dataset.

I tested with both relational (direct query) and OLAP (live connection) data source. I created .pbix with dynamic RLS applied and publish it onto Group1. Pin Dashboard and create content pack within Group1, publish it to Group2. Then add an user which is a member of Group2 into a security role. When this user get data from the content pack, he can view his own data properly.

Regards,

[Tas]

Thanks Simon, 

Yes, despite what the indications are in the PBI Destop UI, and that it is Not mentioned anywhere in the documentation, it turns out that every person who attempts to address the model that has RLS applied has to be a member of at least one role, and it seems so far that each role has to have at least one rule applied.  I have not been able to get access working where people are members of a role and that role has no filter restrictions.  I have had to add filter restrictions that are always false to make this work.

I have found so far that I can manage the access via roles and memberships in the first (dev) group.  I have not yet tested adding members to the roles in the second group (the one using content packs), but your feedback indicates that should work too.

Again, thanks for the help.