We are currently embedding Amazon Quick Sight Q (Generative Q&A) into our application and seeking a method to restrict or filter data dynamically. Since the Generative Q&A Topic doesn’t support parameters for filtering data, we are exploring the use of session tags to achieve this for anonymous users under the Session pricing model. it is important to note that session tags are not applicable for registered users under the User pricing model, meaning data filtering through tags cannot be applied in this model.
Is there a way for us to filter data without changing our current pricing model?
I understand that Row-Level Security (RLS) can be applied, but my concern is the management overhead. Since our client has limited knowledge about RLS, we would need to build a user-friendly UI for them, which could be a long and complex process. With session-based pricing, it seems much simpler as we can directly pass data filters in the parameters and get the filtered results immediately.
If I’m missing something or misunderstanding any aspect, please correct me as I’m still new to Quick Sight.
Hi @Marc - Thanks for the question. The whole idea for RLS is restrict the user as per there role and group. You need to configure once and every time if there is any new user or some permission level change, you need to tweak the RLS table. From end user prospective, there is no change and they should see the data which is require for them.
I will suggest, please do a POC on RLS and see whether your requirement will fulfil or not.
@Sanjeeb2022 :Thank you for your response. We’ve already completed a POC using Row-Level Security (RLS), which does meet the requirements but introduces management overhead.
Returning to my original question: Is there any way to filter data on Generative Q&A topics? We’re trying to restrict or filter the data displayed in our embedded Q&A. This process feels more complex compared to other embedding options, where parameters can be passed to filter data easily. In our case, we’re only seeing options like tag-based rules and user-based rules, which apply at the dataset level rather than the application level, affecting all uses of that dataset.
If I’m overlooking a simpler approach, please let me know, as this seems like a lot of work just to filter data in Generative Q&A.
Hi @Marc - Ok, I have not used the Gen AI filter options in Quick Sight. Let’s hear from other experts. Hi @WLS-DM@WLS-D@David_Wong - any advise on this?
Hello @Marc, and thank you @Sanjeeb2022 for the mention. Unfortunately, you are not overlooking another approach. There are less options to filter data when utilizing the Generate Q&A experience in Quick Sight. Not being able to utilize parameter filtering has been a blocker for one of my clients as well, so I think that would be a good add to this experience.
At AWS, our roadmap is primarily driven by our customers. Your feedback helps us build a
better service. I have tagged this as a feature request.
The only other alternative option I can really think of is, depending on the number of fields you want to restrict, you could have a few versions of the topic where the dataset is restricted with a where clause. Basically, if there are 5 different roles with various data restrictions, there would be 5 datasets linked to specific topics. Then, depending on the user role, you can return a specific topic. That may be the best work-around solution without implementing RLS, but RLS is the only user-based way to manage permissions for the Q&A.
Let me know if you have any further questions, otherwise I will archive this topic for our support team. Thank you!
We’re considering switching to the session pricing model to use the anonymous embed URL via the GenerateEmbedUrlForAnonymousUser API. Since this API supports Session Tags (which is not available in the GenerateEmbedUrlForRegisteredUser API for registered users), I’m trying to confirm if this means that Tag-based Row-Level Security (RLS) can only be implemented with session-based (capacity) pricing for embedded scenarios.
Could you confirm if this understanding is correct? I’m looking to validate information I’ve found, but the documentation has been a bit tricky to interpret. Your feedback would be appreciated!
Hello @Marc, yes, you have the right idea here. If you are embedding Quick Sight anonymously, then you will pay based on the session pricing model rather than the user based model. If you want to switch to anonymous embedding to utilize the tag-based row-level security, then you will be paying for the service differently. Let me know if you have any further questions!