RLS via a rules dataset
QuickSight implements row-level security with a separate rules dataset — a table mapping users or groups to the values they may see:
UserName | Region
asmith | East
asmith | North
bjones | West
The rules dataset must contain a UserName or GroupName column, plus one column per field you want to restrict, matching the field name in the target dataset exactly.
Attach it to the dataset under Permissions → Row-level security. QuickSight then filters every query for that dataset by the viewing user's entitlements. Enterprise edition only.
How rules resolve
A user with no matching row sees no data by default. That is the correct and safe behaviour, and it means you must explicitly entitle every user who should see something.
Leaving a restriction column blank for a user grants access to all values of that field — the mechanism for giving an administrator full visibility without listing every region. This is easy to do accidentally, so audit blanks in the rules table.
Multiple rows for a user are additive: asmith above sees East and North.
Permissions layering
Objects are permissioned separately. A user needs access to the dashboard to view it, and the dashboard carries its dataset access with it — consumers do not need dataset permissions.
Authors need access to the dataset to build analyses on it, and to the analysis to edit it. Sharing an analysis is different from sharing a dashboard: analysis access lets someone change things.
Groups scale far better than individual users, particularly with IAM Identity Center or Active Directory integration on Enterprise.
Testing
There is no full impersonation preview, so test with a real low-privilege account.
Test three cases: a user with one entitlement, a user with several, and a user with none. The third should show an empty dashboard — if it shows everything, the rules dataset is not attached or a blank has granted universal access.