RLS and namespaces error

We have customer portal users that we want to use embeded url dashboards but restrict what data they can see.

We’re going to use RLS to achieve the data security, and we’ve put the portal customers into their own namespace so that regular users in our company can’t “share” something with the portal users directly that doesn’t have the appropriate RLS configured on it (we will have a process for checking the RLS before we allow access in the portal customer namespace).

We added a dashboard and gave access to a group in the portal users namespace, and things were working as expected, however when then adding the RLS we get the message:
“The underlying dataset cannot be viewed from this namespace”

We’ve tried giving the group in the portal customer namespace that the user belongs to access to the RLS dataset but no change. I’m not sure what to try to look for next to work out how to get past this message and googling for the message comes up with no matches.

Any help or pointers appreciated.

Hi @nlp, welcome to the QuickSight community.

If I understand correctly, your customer portal users are able to access the embedded dashboard when you dont have RLS configured, but are running into issues with RLS configured?

Could you please share how the rows in your RLS dataset file looks like?

1 Like

hi @nlp,

Can you please clarify, if the users in namespace are authors and are trying to save the dashboard as an analysis? If not when does this error show up, it is unclear from the description. It would be really helpful if you can share more details and clarification around when the error occurs and what are the configured RLS rules as requested by @SD_QS.

1 Like


yes @SD_QS when RLS is not applied to the dataset the embedded dashboard shows the data as expected, adding the RLS dataset restriction only show that error/message when trying to view the embedded dashboard.

We are using GroupName and the fields we want to filter on in the RLS, we have two filter fields which apply at different levels but each row will only have either the parent or child group filter (but users may have multiple rows with a mix of both):


The users are Reader users, this is just trying to view the embedded dashboard.

Let me know if there are any other clarifications :slight_smile:

Hi Again,

bit more info in case it’s important, both the query dataset and the RLS dataset were created by a user who is in the “default” namespace (the dashboard and analysis also).

We did give permissions to view the dashboard to a group that is in the customer portal namespace (which the customer portal namespace users are all a part of) and that all seemed to work to view the dashboard before the addition of RLS.

We did also add permissions to the RLS dataset and the main dataset for the namespace group in the hope that might resolve things but still seeing the same message.

Thanks again.

Hi @nlp Thanks for providing additional info.

Could you please confirm for us the following:

  1. Do you have 2 groups with the same group name across both the namespaces?
  2. Are you using group names within the RLS dataset to assign permissions?

If the answer to the above questions are yes, could you please try using GroupARNs in your RLS dataset file and check if that solves the issue for you? Thanks.

See below for relevant documentation:

  1. Using row-level security (RLS) with user-based rules to restrict access to a dataset - Amazon QuickSight
  2. Amazon QuickSight Resource ARNs - Amazon QuickSight
1 Like

Thanks @SD_QS,

GroupARNs seem to be working, with the namespace/group name in the resource_id.

To answer your questions:

  1. we started with only having one group with the specific name in the portal namespace but our GroupName didn’t have the namespace included… perhaps we would have had different results if we had have qualified the group name with the namespace? I did add the group to both namespaces to see if that made a difference but didn’t allow access (but still using just the group name with no namespace).

  2. yes we are.

Thanks for the pointers.

Thanks for letting us know, @nlp :slight_smile: