Power BI Administration & Security - FAQs

Yes - Power BI Desktop lets you view a report "as" a specific role before publishing, and the Power BI service supports testing as a specific user post-publication. We always test every RLS role against real user scenarios before go-live, since an untested RLS rule that is too permissive is a data breach waiting to happen, and one that is too restrictive breaks a business user's day.

No - a Power BI app is built from a single workspace's content. Where an organisation needs to present content that spans what would naturally be several workspaces to one audience, this needs to be planned into the workspace and app structure from the outset, rather than solved after the fact.

Yes, with the right configuration - Power BI supports external sharing of apps to guest users via Azure Active Directory B2B, subject to your organisation's tenant-level external sharing settings. This needs to be deliberately enabled and scoped, not assumed to work by default.

Yes — users can access Power BI dashboards from inside Business Central. Power BI reports can be embedded directly into BC pages, so a user looking at a customer record in BC can see the related Power BI analytics on the same screen. The integration uses Power BI's standard embedding capabilities and works for both BC SaaS and BC on-premises with appropriate configuration. The result is that analytical context appears where operational decisions are made, rather than in a separate tool. This is one of the more underused capabilities in BC + Power BI implementations.

Security and governance configuration is built into our standard Analytics Acceleration Programme rather than sold as a bolt-on. Security design happens during the Establish phase alongside architecture and dashboard planning, because retrofitting proper RLS and permissions after dashboards are already built and in daily use is materially more disruptive than designing it in from the outset.

Yes, RLS defined in the underlying semantic model continues to apply exactly as it does for any other consumption method. An app is a distribution and navigation layer; it does not bypass or replace the security already built into the semantic model beneath it.

Three rules make Power BI reports accessible. Never use colour as the only signal of meaning. Always check that contrast is sufficient, particularly for grey text on light backgrounds. Test the report at different zoom levels and on different screens. Power BI has accessibility tooling built in, and the checklist has a full category dedicated to accessibility. Most accessibility issues are easy to fix once seen, and invisible until pointed out.

The underlying RLS mechanism in the semantic model works the same way, but tenant-level governance features available in the cloud admin portal - centralised usage monitoring through Purview audit logs, some sharing and certification features - are more limited or entirely unavailable on Report Server. Governance has to be designed around what the on-premises platform actually supports, not assumed to match the cloud experience.

Apply sensitivity labels at the dataset level for content that needs them, propagate to derived content automatically. Microsoft Purview is the underlying tool. The discipline is deciding which datasets warrant labels and applying them consistently. The mistake is applying labels inconsistently or not at all, then hoping nothing sensitive ever flows into the wrong report. Labels are a one-time setup with ongoing operational benefit.

We control who can access a published Power BI app through defined audiences within the app, each of which can be assigned specific content and specific security groups or individuals, all managed from within the app publishing settings rather than through workspace roles. This lets a single app serve genuinely different audiences with different visible content from one underlying workspace.

To get a security review of our existing Power BI estate, even if Hopton did not build it, email hello@hoptonanalytics.com describing your current Power BI setup and any specific concerns. We regularly review existing estates - built by us or by others - and can scope a focused security and governance assessment independent of any wider engagement.

We handle Power BI version control when multiple people update a workspace before an app republish through the same workspace-level version history and review discipline that should already govern production content, combined with a clear internal process for who reviews and triggers the app republish. The app republish step is a natural checkpoint to enforce this review, and we build that checkpoint deliberately into governance design.

We monitor who is actually accessing what in Power BI through Power BI's built-in usage metrics reports, and more comprehensively through the Microsoft Purview audit log, which records detailed activity across the tenant - who viewed, edited, or shared specific content and when. We set this up as standard on governance-focused engagements, since usage data is also valuable for licensing and content rationalisation decisions.

We decide what goes into an app versus what stays workspace-only by identifying which reports are genuinely finished, validated, and intended for a specific audience, versus which are still in development or intended only for the report-building team. We treat this as a deliberate curation decision during design, not an afterthought once reports happen to exist in a workspace.

We decide what level of security a given Power BI deployment actually needs by understanding what data is genuinely sensitive (financial detail, personal data, commercially confidential information), who legitimately needs to see what, and what the real consequence of over-exposure would be. This is a discovery conversation, not a checklist applied uniformly to every client.

RLS is configured through roles defined in the semantic model, each with a DAX filter expression (for example, restricting a sales table to rows where region equals the current user's assigned region), and then mapping specific users or Azure Active Directory groups to those roles in the Power BI service.

A workspace is where content is built, tested, and collaborated on; it is inherently a working environment and usually includes draft or in-progress reports alongside finished ones. An app is a separate, read-focused distribution layer built from a workspace's content, letting you control precisely what a wider audience sees without exposing the workspace itself or requiring workspace-level roles.

Neither extreme — one workspace for everything, or many — works well. A single workspace for an entire organisation makes permission management unwieldy and increases the blast radius of a mistake; a separate workspace per report fragments governance and makes reuse of shared datasets harder. We typically structure workspaces around business functions or departments, each with a clear owner and a defined publishing process.

Access to workspaces should be governed through Entra ID groups, not individual user assignments. Create groups for each role (Finance Authors, Finance Viewers, Sales Authors, etc.) and assign the groups to workspaces. New starters get added to the right groups based on their role and inherit the right access automatically. Leavers get removed from the groups and lose access automatically. Individual user assignments accumulate and are easy to forget. Group-based access is sustainable.

At scale, workspaces should be structured as Dev, Test, and Prod workspaces per domain. Finance Dev, Finance Test, Finance Prod. Sales Dev, Sales Test, Sales Prod. The pattern protects production from accidental changes and gives you a place to test changes before they affect users. The cost is some workspace overhead and the discipline of using deployment pipelines. The benefit is that change becomes routine rather than risky.

Yes — it is possible to over-engineer Power BI security for a mid-market organisation. Highly granular, enterprise-grade security models designed for organisations with thousands of users and complex regulatory requirements can be genuinely counterproductive for a fifty-person business, adding maintenance overhead without a matching risk to justify it. We size the security model to the organisation's actual risk profile, not to a theoretical maximum.

Static RLS (a separate role manually maintained for each user or group) works for small, stable user populations where role assignment rarely changes. Dynamic RLS (where the filter expression references a table mapping users to their permitted data, so no manual per-user role maintenance is needed) scales far better and is what we recommend for any organisation beyond a handful of report consumers.

Yes — administrators should be trained separately from report builders, even if it is the same person, because the skill sets are genuinely different. Workspace security, capacity management, and tenant governance settings are administrative concerns distinct from data modelling and DAX, and combining them into one generic session tends to under-serve both topics.

Business users should generally not publish their own reports directly to production workspaces. We recommend separating a development or self-service workspace, where trained users can build and test their own reports, from certified production workspaces, where only reviewed and approved content is published for wider consumption. This preserves self-service flexibility without compromising the trust of governed reporting.

Not every employee should be able to create their own Power BI workspace by default, in most mid-market organisations. Unrestricted workspace creation tends to produce sprawl - many small, ungoverned workspaces with unclear ownership. We generally recommend restricting workspace creation to a defined group, with a clear request process for anyone else who needs one.

Sensitivity labels, part of Microsoft Purview Information Protection, classify reports and datasets by confidentiality level (for example, Public, Internal, Confidential) and can enforce protections such as restricting export or requiring encryption based on that classification. They matter most for organisations with genuine confidentiality tiers to enforce, or regulatory requirements around data classification.

Governance for self-service authors starts, in practice, with naming conventions for new content. Required ownership before content can be promoted. A review path before content reaches the main audience. A retirement process for content that no longer earns its place. The discipline is the same as central-team governance, applied lightly to fit how self-service authors work. The mistake is either no governance (sprawl) or heavy central-team governance (kills the self-service value). The middle path is fast review against a clear standard.

When self-service authors are ungoverned, the estate becomes sprawl. Different authors build different reports answering similar questions with different definitions and different time windows. The certified semantic models get bypassed. The same problems that drove the original push for self-service reappear, but distributed across many more authors. Self-service authors need the same governance discipline as the central team, applied appropriately to their level. Without it, self-service is a sprawl factory.

Governed self-service analytics is the balance between letting the business build its own reports and keeping everyone working from trusted, consistent numbers. In Power BI that means certified datasets, a semantic model that defines each measure once, clear workspace ownership, and row-level security applied consistently. Supported by training and a Centre of Excellence operating model, it lets self-service scale without descending into conflicting versions of the truth.

RLS restricts which rows of data a given user can see within a shared report, based on rules defined in the semantic model - for example, a regional sales manager seeing only their region's data while a national director sees everything, from the same underlying report rather than separate copies of it.

The Power BI admin portal controls tenant-wide settings: export restrictions, external sharing rules, workspace creation permissions, and usage monitoring, among others. Access should be restricted to a small number of genuinely responsible administrators, since tenant-level settings affect every workspace and user across the organisation.

The difference between report consumer, report builder, and administrator training is that report consumer training covers navigating dashboards, using filters and slicers, drilling into detail, and exporting data - typically a short session for a broad audience. Report builder training covers data modelling, DAX measures, Power Query transformations, and report design - a deeper, longer programme for a smaller group of power users or analysts. Administrator training covers workspace management, security configuration, capacity management, and tenant governance - for the small number of people who will actually administer the platform.

The difference between workspace roles and RLS is that workspace roles (Admin, Member, Contributor, Viewer) control what a user can do with content - build, edit, publish, or only view - within a workspace. RLS controls what data a user can see within a report they already have access to. The two work together: workspace roles gate access to content, RLS gates access to specific rows within that content.

The most common Power BI security mistake you see in mid-market organisations is treating workspace access as the only security control and not implementing RLS at all, on the assumption that "everyone in the department should see everything." This usually turns out not to be true on closer inspection, and retrofitting RLS onto reports that were built without it in mind is more disruptive than building it in from the start.

Row-level security should live at the model layer, not the report layer. RLS defined in the model is applied consistently across every report built on the model. RLS defined in individual reports has to be replicated everywhere and is easy to miss. Model-layer RLS is one of the foundational disciplines for Power BI at scale. It gets less attention than capacity sizing but matters more for actual security outcomes.

Only viewers (read-only) should have access to Prod workspaces. Authors should not have direct write access to Prod. Changes go through deployment pipelines from Test. Service accounts or specific governance roles can have admin rights to Prod for emergency changes, but the default should be that Prod content is changed through the pipeline, not through direct edits in the workspace. This is the discipline that protects the production estate.

Power BI makes it very easy to publish reports quickly, which is both its strength and the source of most governance problems. Without defined metric standards, certified datasets, and workspace governance, the environment grows organically with each person applying their own definitions. The result is multiple reports showing different numbers, leadership unable to trust any of them, and data teams spending more time reconciling than analysing.

Security gets messy at scale because access tends to accumulate. Someone gets added to a workspace for a project and stays there. New starters get added to the workspaces their predecessors had access to, even if those predecessors had different roles. Row-level security gets applied report-by-report rather than at the model layer. Over time, the security picture diverges from what would be granted today if you started fresh. Periodic access reviews are the answer.

You can give report viewers Viewer access to the workspace directly, and for a small number of trusted, technically comfortable users this is sometimes simpler. But workspace Viewer access exposes everything in the workspace, including anything still in development, and does not give you the same curated navigation experience, custom audience grouping, or update-notification behaviour that an app provides. For any broader or less technical audience, an app is the better-designed option.