Power Bi Controls
You set up power bi controls by combining workspace roles, row rules, and tenant settings. These native rules decide who can view reports, edit datasets, and share dashboards. Most data teams start by assigning workspace roles to user groups in the cloud. They also add row rules to filter report tables based on who logs in. Still, teams often attach shared database keys to those datasets to keep reports running. When roles or database permissions are too broad, users can pull raw sensitive recor
GCP VPC Service Controls: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up power bi controls by combining workspace roles, row rules, and tenant settings. These native rules decide who can view reports, edit datasets, and share dashboards. Most data teams start by assigning workspace roles to user groups in the cloud. They also add row rules to filter report tables based on who logs in. Still, teams often attach shared database keys to those datasets to keep reports running. When roles or database permissions are too broad, users can pull raw sensitive records. A report builder with edit rights can bypass visual filters and read full tables.
How native power bi controls work
Native power bi controls work across three main layers inside your reporting platform. The first layer is the tenant admin portal, which governs sharing and export rules. Admins use these settings to block public web links and stop raw file downloads. The second layer is the workspace, where teams manage folders of reports and datasets. Workspace roles let you split report readers from report builders and workspace admins. Viewers can only look at charts, while builders can alter queries and data models.
The third layer happens inside the data model using row and object rules. Row rules filter data rows by matching a user email to a table column. Object rules hide specific tables or columns from users who lack the right role. When a viewer opens a chart, the platform checks their identity and applies filters. This setup works well when users only view fixed charts in the web app.
What native controls solve and the gap they leave
These native features solve the problem of who can open dashboards in the browser. They keep normal business viewers from seeing other regions or downloading full spreadsheets. They also help admins stop users from sharing internal charts with outside guests.
Still, native rules leave a large gap at the database query layer. The reporting tool often uses one shared service account to query your production database. The database sees the shared service account rather than the real person running queries. Native workspace rules only decide who logs in to the reporting app. They do not inspect what individual database queries do in flight. Anyone with dataset build rights can write custom queries using that shared database key. They can pull unmasked emails, phone numbers, card numbers, or national IDs into desktop tools. Also, database logs only show the shared account name, which breaks user audit trails.
GCP VPC Service Controls: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Managing dataset permissions and shared credentials
To reduce risk, teams must lock down who gets build permissions on shared datasets. You should separate workspaces that hold data models from workspaces that only hold reports. Give most analysts viewer rights and limit who can edit the base data query. Even with strict workspace roles, the shared database account still holds wide read rights. If a single dataset owner makes a mistake, sensitive columns enter the report cache. Data masking at the query layer rewrites matched fields in results before caching happens. This keeps card numbers and national IDs out of the reporting memory store.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Do row rules protect data when users have workspace edit rights?
No, row rules only filter data for users with the workspace viewer role. Users with admin, member, or contributor roles can view all rows in the dataset by default.
Why do database logs only show one user for all report queries?
Most datasets use a single stored service account to query the backend database. The database logs that shared account name instead of the individual report viewer.
How can teams protect emails and card numbers in imported datasets?
Imported datasets store raw values in memory once the refresh query finishes running. Rewriting matched fields in query results before they reach the report keeps data safe.