Tableau / Advanced: quality and governed delivery / Lesson 15

Permissions, user filters and row security

Separate content capabilities from allowed data rows, and design identity-based tests without using visual filters as security.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Distinguish permissions, identity and row restrictions.
Review entitlement mappings and unknown-user behavior.
Protect security logic across editing and download paths.

Separate content and row access

Permissions control capabilities such as viewing, editing or downloading content, while row-level security restricts the data population a user can see. A visible region filter or hidden worksheet is not a complete row-security boundary. Start with the actual authenticated identity and approved data entitlements. The same dashboard can legitimately return North 30 to one user and South 30 to another while an unrestricted author sees 60. Do not judge those totals using one universal oracle. This course reads no identities or permissions and uses reserved example principals only. An access test needs both the intended consumer capabilities and expected allowed rows.

Read an entitlement-filter assumption

The first expression is meaningful only within a governed source model containing an appropriate Allowed User entitlement and supported identity behavior. It is not a complete security solution by itself. USERNAME can differ in representation across local and hosted contexts, so validate the actual identity format through an authorized process. Missing mappings should fail closed under the approved design. Entitlement joins can also duplicate facts if several matching grants are flattened incorrectly. Reconcile both allowed keys and amounts. Never place actual usernames, tokens or private entitlement exports into public teaching evidence.

tableau Unexecuted entitlement comparison

[Allowed User] = USERNAME()

Assume a reviewed entitlement model and protected filtering layer. This fragment does not create permissions, publish a source or prove enforcement.

Protect the enforcement layer

A workbook filter that a consumer can edit or remove does not provide the same assurance as a governed protected data-source or connection policy. Review publishing, editing, downloading and alternate source access together. Tableau documents several RLS approaches, including virtual-connection data policies when the required entitlement/features are available; do not assume every deployment includes them. Select a supported design with its owner and effective permissions. A local preview as author does not prove hosted enforcement. No permission, source, policy or connection is created here, and no administrative tool or API is invoked.

Model known and unknown principals

The second program maps a synthetic principal to North and gives an unknown principal an empty set. It demonstrates an intended fail-closed population only, not Tableau identity resolution or effective permissions. The North rows total 30. A broader entitlement can legitimately change the result and must be reviewed rather than hidden with a view filter. Keep allowed and denied records in acceptance, along with multi-grant and no-mapping cases. A security implementation that merely lets a report open has not demonstrated that unauthorized rows stay absent through every supported consumption route.

python Synthetic fail-closed population

entitlements = {"reader@example.test": {"North"}}
rows = [("North", 12), ("North", 18), ("South", 30)]
for user in ("reader@example.test", "unknown@example.test"):
    allowed = entitlements.get(user, set())
    print(sum(amount for region, amount in rows if region in allowed))

Expected output

30
0

30 and 0 reflect this in-memory mapping only. No account, authentication provider, workbook or server is accessed.

Review effective consumer evidence

Define known North and South users, unknown identity, multiple entitlements and an editing/download-capability case. Specify expected rows and aggregates rather than only successful navigation. Verify actual product/version and protected source design through authorized evidence. This course runs only set membership and no login or access test. A complete handoff separates identity format, entitlement maintenance, content permissions, enforcement layer and observed results. Preserve unresolved risks and do not call a hidden control or one successful author test proof that private data is secured. Security acceptance must follow the intended consumer, not the author’s unrestricted view.

Common errors and fixes

A region filter is presented as sufficient row security

Why it happens: Presentation filtering replaced protected enforcement.
How to fix it: Use an approved governed RLS design and effective permission review.
Prevent it next time: Test alternate editing and data-access paths.

Unknown identity receives a broad default population

Why it happens: Missing-mapping behavior was not defined safely.
How to fix it: Implement the approved fail-closed rule and diagnostic ownership.
Prevent it next time: Keep no-mapping acceptance cases.

Author preview is treated as consumer security proof

Why it happens: Identity and capabilities differ between test and intended user.
How to fix it: Validate the actual supported consumer scenario separately.
Prevent it next time: Record exact identity context and expected denied data.

Check your understanding

1. Why is the username comparison not a complete RLS deployment?

Show worked solution

It needs correct identity representation, entitlement data, relationship/filter placement and protected permissions across viewing, editing and download routes. The fragment establishes none of those by itself. Design and verify the whole enforcement boundary under the intended consumer identity, using synthetic evidence rather than exposing real grants.

2. What does unknown-user 0 in the program prove and not prove?