Who this is for
BI Developers and Analytics Engineers who publish dashboards, manage datasets, and must ensure only the right people see the right data.
Prerequisites
- Basic understanding of BI workspaces/projects and publishing content.
- Familiarity with row-level security (RLS) and column-level security (CLS) concepts.
- Ability to create user groups in your identity provider (e.g., company directory).
Why this matters
Real tasks you’ll face:
- Share a sales dashboard so each region only sees its own data.
- Invite an external agency to a workspace without exposing PII.
- Let analysts build reports while preventing them from changing production content.
Done well, you prevent data leaks, reduce manual fixes, and pass audits with confidence.
Concept explained simply
Think of your BI platform as a building:
- Workspaces/Projects are the rooms. Workspace permissions control who can enter and what they can do (view, edit, publish).
- RLS/CLS are window blinds inside the room. Even if someone enters, blinds restrict what lines and columns of data they can see.
- Sharing is handing out a room key. It should go to groups, not individuals, and match the least privilege needed.
Mental model
Layered security:
- Identity (users and groups)
- Workspace/Project role (Viewer/Contributor/Admin etc.)
- Object permissions (dataset, reports, data sources)
- Data-level rules (RLS/CLS, masking)
Always design top-down (groups and roles) and test bottom-up (what a specific user can actually see).
Key principles
- Least privilege: start with Viewer and add only what’s required.
- Groups over individuals: assign permissions to groups; add users to groups.
- Separate dev/test/prod: don’t test security in production first.
- Inherit and override carefully: prefer inheritance; document any overrides.
- Never bypass RLS/CLS: test with real user accounts, not just admin preview.
Worked examples
Example 1: Power BI — Share a regional sales report safely
- Create AAD groups: Sales-EMEA, Sales-AMER, Sales-APAC; one broader group Sales-Viewers.
- Implement RLS in the dataset: Role EMEA filters Region = "EMEA"; similar for AMER, APAC.
- Map groups to RLS roles: Sales-EMEA → EMEA role, etc. Sales-Viewers gets no role unless needed.
- Workspace roles: Assign all Sales-* groups as Viewer in the production workspace.
- Share report: Share with Sales-Viewers group (Viewer). Only those mapped to RLS roles see rows; others see nothing or only permitted rows.
- Test: Use a test account in Sales-EMEA to confirm only EMEA rows appear; columns with PII are hidden via model permissions or report-level removal.
Why safe: Viewers cannot publish/modify. RLS ensures per-region visibility.
Example 2: Tableau — Project permissions with row and column controls
- Create groups: Finance-Viewers, Finance-Analysts, Agency-Partner.
- Project permissions: Finance-Viewers = View; Finance-Analysts = View + Web Edit; Agency-Partner = View only.
- Row-level: Add data source filters using USERNAME() or group membership to filter to permitted business units.
- Column-level: Use calculated fields with IF CONTAINS(USERNAME(), ...) THEN [PII] ELSE NULL or leverage data source policies to mask PII.
- Publish workbooks to Finance project, ensuring permissions inherit from the project.
- Test with an Agency-Partner user to confirm masked columns and filtered rows.
Example 3: Looker — External partner access with access_filters
- Create group Partner-BrandA.
- Model permissions: Set access_filters for users in Partner-BrandA to Brand = 'A'.
- Use access_grants (or equivalent) to restrict sensitive fields to only internal groups.
- Content access: Share folders/dashboards as View to Partner-BrandA.
- Test using an account in Partner-BrandA; verify Brand A rows only and sensitive fields hidden.
Step-by-step: Secure sharing setup
Create groups by business role and data slice (e.g., Sales-EMEA-View, Sales-AMER-View, Execs-View, Analysts-Build).
Assign Viewer to consumers, Contributor to content creators, Admin to platform owners only.
Build RLS roles by region/business unit; apply CLS/masking for PII fields.
Share reports/dashboards to the least permissive group that meets the need.
Use a test user per group; confirm both row and column restrictions.
Record the permission matrix (who gets what and why) and review quarterly.
Exercises
Complete these tasks, then compare with the solutions.
Exercise 1 — Build a permission matrix (mirrors ex1)
Design a permission matrix for a BI workspace containing: 1 dataset (Sales), 2 reports (Regional Sales, Executive Summary). Users: Regional Sales teams (EMEA, AMER), Executives, Data Analysts.
- Map each group to a workspace role.
- Define RLS roles for regions.
- Decide who can Build on the dataset.
- List who can access each report.
Exercise 2 — External sharing with masking (mirrors ex2)
An external agency should see only their brand’s marketing data and never any emails/phone numbers.
- Outline steps to provision access safely.
- Include workspace role, group, RLS, and CLS/masking.
- Add a test plan for validation.
Need a nudge?
Start from groups, not users. Ensure Viewers do not get edit rights. Use masking or access grants for PII.
Pre‑share checklist
- [ ] Permissions assigned to groups, not individuals
- [ ] Workspace role is least privilege (Viewer unless needed otherwise)
- [ ] RLS roles tested with real user accounts
- [ ] Columns with PII masked or removed for non-cleared users
- [ ] External users isolated to a dedicated group
- [ ] Permission matrix documented
Common mistakes and self-check
- Mistake: Giving Contributor to all consumers. Fix: Use Viewer for consumers; Contributor only for creators.
- Mistake: Assuming RLS applies to all roles equally. Fix: Confirm how your tool treats dataset owners/builders; test with a viewer-level account.
- Mistake: Hiding columns in the report only. Fix: Enforce CLS/masking at the model or data source level.
- Mistake: Sharing to individuals. Fix: Share to groups to simplify audits and changes.
- Mistake: Testing with admin preview only. Fix: Log in as a test user in the target group.
Practical projects
- Project 1: Create a two-tier workspace (Staging and Production). Implement identical RLS/CLS and a release checklist.
- Project 2: Build a permission matrix for your org. Include groups, workspace roles, object permissions, RLS/CLS, and owners.
- Project 3: Implement a PII masking policy. Prove it works by screenshots from two test users with different clearances.
Learning path
- Start: Define groups and map workspace roles.
- Next: Implement RLS (rows) and CLS/masking (columns).
- Then: Share content to groups, not users.
- Finally: Test with real accounts and document the matrix.
Mini challenge
In one paragraph, describe how you would safely share a company-wide KPI dashboard where executives see all data, managers see their department only, and contractors see only anonymized metrics. Include workspace roles, RLS, and CLS.
Next steps
Apply these steps to one real dashboard this week. Review permissions with a stakeholder and capture gaps for improvement.
Quick Test
Everyone can take the test for free. Only logged‑in users will have their progress saved.