QuickSight Dataset shows "Failed to update user-based row-level security" when applying RLS

Row-Level Security (RLS) lets you control which rows of data each user or group can see in a shared dataset without creating multiple copies of it. It's available in the Enterprise Edition of Amazon QuickSight.

At its core, RLS relies on a permissions dataset (also called a "rules dataset"). This dataset defines who can see what.

Column Type	Purpose
Identity column :UserName, GroupName (or their ARN equivalents)	Identifies the user or group the rule applies to
Restriction columns : one or more columns that match fields in your main dataset	Specifies the allowed values for those fields

Each row in the permissions dataset is a rule:

"This user/group can see rows where these field values match."

Key Behaviors

Scenario	What the user sees
User has a matching rule with specific values	Only rows matching those values
User has a rule but all restriction columns are NULL	All data (full access)
User has no rule at all	No data
User is a dataset owner	All data (owners bypass RLS)
User is a dataset reader	Only what the rules permit

Common Error: "Failed to update user-based row-level security"

When applying RLS, you may encounter this error:

"Failed to update user-based row-level security"

This error is generic and does not tell you the exact reason for failure. Based on common support cases, the most frequent causes are:

1. Column Name Mismatch

The columns in your permissions dataset do not exist in the target dataset. Column names must match exactly (they are case-sensitive). Example: Your main dataset has a field called SalesRegion, but your permissions dataset references Sales_Region — this will fail silently.

2. Misspelled Column Names

A simple typo in a column name (Segmnet instead of Segment) will cause the apply to fail.

3. Conflicting Rules

Creating rules that both grant and deny access to the same column for the same user or group can cause conflicts.

Troubleshooting Checklist

• Verify that every restriction column in the permissions dataset matches a field name in the main dataset — character for character.
• Check for trailing spaces or invisible characters in column headers.
• Ensure no duplicate or contradictory rules exist for the same user/group.
• Confirm all columns in the permissions dataset are of string type.

FAQs:

1. What Happens When a User Belongs to Multiple Groups?

Scenario: A user belongs to Group A and Group B. Both groups have RLS rules that restrict access to different subsets of rows.

Answer: The user gets the union (additive combination) of all rules applied to them, both direct rules and group-based rules. Each rule acts as an additional filter allowance.

Think of it as: Rule 1 OR Rule 2 OR Rule 3 — the user can see any row that matches at least one of their applicable rules.

Example

GroupName	Segment
Group-SMB	SMB
Group-Enterprise	Enterprise

A user belonging to both Group-SMB and Group-Enterprise will see rows where Segment = SMB OR Segment = Enterprise.

Here's the rule dataset:

Here's the final view for a user who belongs to both the groups:

The rules are additive -> they expand access, they don't further restrict it.

2. What Happens When a User has a direct rule AND belongs to a group?

Scenario: Suppose you have a Rules Dataset where you include both a GroupName and a UserName and there are two separate rules that allow Group access to a particular set of rows and the individual user has another rule that allows this user access to another set of rows

Example:

UserName	Segment
Martha	Enterprise

GroupName	Segment
Sales-US	SMB

→ Martha (member of Sales-US) sees rows where Segment = Enterprise OR Segment = SMB. Both rules apply additively.

3. What Happens When One group has full access (NULL rule)

GroupName	Segment
Sales-US	SMB
Executive-Team	(NULL)

→ User in both Sales-US and Executive-Team sees all data — the NULL rule grants full access, and it "wins" since rules are additive.

4. What happens when User belongs to a group but has no individual rule**

GroupName	Segment
Sales-US	SMB

→ A user who is not in Sales-US and has no direct UserName rule sees no data at all.

Key takeaway: Rules never subtract from each other. If any applicable rule grants access to a row, the user sees it. The only way to restrict is to ensure the user/group simply doesn't have a rule for those values.

---

References:

[+] Using row-level security with user-based rules: https://docs.aws.amazon.com/quicksight/latest/user/restrict-access-to-a-data-set-using-row-level-security.html