[Bug?] RLS NULL row ignored by query_dataset API when user also has explicit permission rows — Dashboard works correctly

Q&A
, ,
1

Environment:

  • QuickSight Enterprise Edition
  • Region: us-east-1
  • Direct-connect dataset with user-based RLS

Issue:
When a user has both explicit permission rows AND a NULL (all-access) row in the same RLS permissions dataset, the behavior is inconsistent between Dashboard and API:

Access Method NULL Row Behavior Result
Dashboard (UI) :white_check_mark: Recognized as full access User sees all data
query_dataset API (via Amazon Q / Quick Desktop) :cross_mark: Ignored User only sees data matching explicit rows

RLS Configuration (simplified):

username | rls_territory | rls_other_cols

------------|----------------------------------|---------------

user_a | TERRITORY-A, TERRITORY-B, … | NULL

user_a | TERRITORY-C, TERRITORY-D, … | NULL

user_a | TERRITORY-E, TERRITORY-F, … | NULL

user_a | NULL | NULL ← should grant full access

Per official documentation:

“If you add a rule for a user or group and leave all other columns with no value (NULL), you grant them access to all the data.”

Expected behavior: The NULL row should grant full access regardless of other rows — both in Dashboard and API.

Actual behavior: Dashboard correctly interprets the NULL row. API (query_dataset) only applies the explicit territory rows, ignoring the NULL row entirely.

Reproducible: Yes — confirmed with 2 different users who have the same RLS pattern. Both see full data in Dashboard but restricted data via API.

Workaround: Remove all explicit rows and keep only the NULL row — then both Dashboard and API work correctly. However, this workaround requires restructuring the RLS dataset, which may not always be feasible.

Questions:

  1. Is this a known limitation of the query_dataset API vs Dashboard rendering?
  2. Is the expected behavior that NULL row + explicit rows should be evaluated as OR (union) — i.e., NULL wins?
  3. Is there a best practice for granting full access to admin users who also need explicit rows for other systems that share the same RLS dataset?

Thanks for any guidance!

2

Hi @chcccchiii ,

The Dashboard treats each permission row as a standalone rule and unions the results, so when it sees a row for user_a with all filter columns NULL, it correctly interprets that as “grant full access,” and that row wins. The query_dataset API appears to instead aggregate all filter values for a user across rows into a per-column IN-list. When it hits a NULL in rls_territory, it discards it as “no value” but it still applies the explicit territory values from your other rows. The grant-all semantics of that NULL row get lost in translation.

Based on my expereince and from reviewing some of the AWS documentation, the general rule says a row with a valid username and all-NULL filter columns grants full access. But the “Important” callout says QuickSight skips “empty rules” to prevent accidental over-exposure and the API seems to apply that logic more aggressively than the Dashboard does. By the strict definition your row isn’t an empty rule (the username is populated), so the Dashboard has it right and the API has it wrong.

To answer your questions directly:

  1. Not a documented limitation as this looks like a bug. Worth filing with AWS Support with your reproducible test case.

  2. Yes, the intended behavior is OR/union across rows, with the NULL row granting full access regardless of other rows.

  3. The short-term workaround is to avoid mixing a NULL-filter row with explicit-filter rows for the same user, which is what triggers the inconsistency. The right long-term fix for admin users who need full access will depend on your specific setup