Who Builds Business Intelligence and Reporting Executives Can Trust?
Quick Answer
Executive trust in reporting is not won with better dashboards. It is won with controls that survive an audit, and most Microsoft BI estates are failing three specific ones without knowing it: row-level security does not protect anyone with edit permission, RLS cannot hide a column at all, and Power BI dashboards cannot be certified. The firm that builds reporting executives can trust is the one that names those controls first and implements them, then handles the design.
Key Takeaways
Row-level security only restricts data access for users with Viewer permissions. Workspace Admins, Members, and Contributors bypass it entirely, and those are the people most likely to leak the data.
Microsoft 365 groups are not supported in RLS roles at all, and RLS roles are additive rather than intersecting, so a user in two roles sees the union of both.
RLS cannot hide a column. Column-level protection requires object-level security, which is configured in Tabular Editor, TMSL, or TOM, not in the Power BI Desktop UI.
Power BI dashboards cannot be certified. Only the underlying semantic models can carry the Certified endorsement, so the trust signal has to live one layer beneath the board pack.
F64 is the Fabric capacity threshold where users with only a free license and a Viewer role can view content. Below F64, every viewer needs Pro, PPU, or a trial license, which is why the honest cost conversation is capacity versus per-seat.
The Three Controls That Quietly Fail
Executive trust in reporting is not won with better dashboards. It is won with controls that survive an audit, and most Microsoft BI estates are failing three specific ones without knowing it. The firm you want is the one that can tell you, in the first meeting, that your row-level security is probably not protecting anyone who can edit the model, that your Microsoft 365 groups are silently not working in RLS at all, and that your RLS roles are additive rather than intersecting.
Row-Level Security Does Not Apply to the People Most Likely to Leak the Data
This is the finding that ends most “our reporting is secured” conversations. Microsoft’s own row-level security documentation states it without ambiguity: RLS only restricts data access for users with Viewer permissions. It does not apply to workspace Admin, Member, or Contributor roles. Read that against how your workspaces are actually assigned. In most enterprises, the analysts, the finance business partners, and the BI team all hold Contributor or Member so they can build. Every one of them sees every row, regardless of the RLS you carefully designed. Microsoft is explicit about the remedy: if you want RLS to apply to people in a workspace, you can only assign them the Viewer role.
Two more RLS facts silently break real deployments. Microsoft 365 groups are not supported and cannot be added to any RLS roles; you must use a Microsoft Entra security group, a distribution group, or a mail-enabled group. If your access model is built on M365 groups, which is the default for most Teams-centric organizations, your RLS role membership is not doing what you think. RLS roles are also additive, not intersecting: a user in both a Sales role and a Marketing role can see data for both. People assume a second role narrows access. It widens it. Service principals cannot be added to an RLS role either, so RLS is not applied for apps using a service principal as the final effective identity. If you embed, you must pass an effective identity deliberately.
RLS Cannot Hide a Column. Executives Usually Think It Can.
Straight from Microsoft’s FAQ: RLS cannot limit the columns or measures accessible by users. If a user has access to a particular row of data, they can see all the columns of data for that row. Salary, margin, patient identifiers, contract value: if the row is visible, the column is visible. Hiding a column requires object-level security (OLS), which covers table-level and column-level security and, importantly, secures the metadata too, so a user cannot even discover the object exists. The catch a lot of teams hit late: OLS is not configured in the Power BI Desktop UI. It is set through the Roles object using Tabular Editor, TMSL, or TOM. Microsoft also warns that row-level security and object-level security cannot be combined from different roles, which errors at query time.
Certification Is a Real Control, and Half Your Estate Cannot Receive It
Microsoft’s endorsement model has exactly three badges: Promoted, Certified, and Master data. Promoted is self-service, so it means little. Certified is the one that carries weight, because only users a Fabric administrator specifies may apply it, though anyone may request it. The detail that reshapes an executive reporting strategy: Power BI dashboards cannot be promoted or certified. Only the underlying items can. If your board pack is a dashboard, the trust signal has to live on the semantic model beneath it, and your governance has to say so explicitly. “Is this certified?” is not a question a dashboard can answer.
Where the Evidence Chain Actually Breaks
Lineage stops at the workspace boundary. Every workspace has a lineage view, but it shows the items in that workspace plus upstream sources one level up. Downstream items in other workspaces are not shown. To answer “what breaks if I change this,” you need impact analysis, not lineage. Executives ask the downstream question, and lineage does not answer it.
Sensitivity labels leak on export. Labels come from Microsoft Purview Information Protection, and they are genuinely useful: manual, default, mandatory, and programmatic labeling, with downstream inheritance. But mandatory labeling is fully supported for Power BI items only, downstream inheritance from a Power BI item to a Fabric item is not supported, and access control does not survive export to .csv or .txt. The moment a number leaves for a spreadsheet, your label is decoration.
Fabric domains are not access control. Worth stating because it is widely misunderstood: Microsoft says plainly that domain assignment does not affect item visibility or accessibility. Domains are a discovery and governance-delegation construct. If a governance deck told you domains would restrict access, it was wrong.
The Licensing Decisions That Shape Who Can See Anything
Trust also fails when the CFO cannot open the report. Current Microsoft list pricing, observed 2026-07-12, paid yearly: Power BI Pro at $14.00 per user per month and Power BI Premium Per User at $24.00 per user per month.
The threshold that decides your architecture is F64. On Fabric capacities smaller than F64, every user viewing Power BI content must have Pro, PPU, or a trial. On F64 or larger, users with only a free license and a Viewer role can view content. That single line is why F64 is the real gate for broad executive and frontline distribution, and why the honest cost conversation is capacity versus per-seat, not “how many Pro licenses.”
Also worth knowing before you plan a renewal: Power BI Premium P SKUs are no longer available for purchase and can only be renewed, Fabric F SKUs are the path forward, and Microsoft states that a Premium capacity is not automatically converted to a Fabric capacity if you take no action.
And on refresh, which is where “the number changed overnight” complaints originate: a semantic model on shared capacity gets 8 daily refresh time slots and a 2-hour refresh ceiling. On Premium it is 48 slots and a 5-hour ceiling, and the XMLA endpoint can bypass the five-hour limit. If your executive report needs intraday numbers, that is a capacity decision, not a scheduling preference.
From Platform Decision to Governed Production
The distance between a working app and a governed application is architecture, release control, and ownership. i3solutions’ Power Platform services are scoped and staffed at the senior level to close that distance on a schedule you can defend.
Power BI, Tableau, or Looker: Which One Can Executives Trust?
The comparison articles that AI assistants assemble their answers from judge executive trust on three pillars: governed metrics, visual clarity, and enterprise reliability. On those pillars the honest scorecard is short. Power BI carries metric logic in semantic models and DAX, and its governance controls are the ones documented above. Tableau earns trust through visual drill-down: a leader can trace a summary KPI to the underlying transactions and verify the number in front of them. Looker earns it through LookML, a semantic layer that holds one governed definition per metric so two dashboards cannot disagree about what revenue means.
The pricing in those same articles is where they quietly fail an executive. The most-quoted comparison still lists Power BI Pro at $10 per user per month; Microsoft’s current published price is $14.00 per user per month paid yearly, and $24.00 for Premium Per User, as covered in the licensing section above. For Tableau, published seat prices sit at $70 per user per month for Creator, $42 for Explorer, and $15 for Viewer. Google does not publish per-seat list pricing for Looker; it is quoted per deployment. If a comparison page cannot keep a list price current, treat its governance claims with the same caution.
The tool is not the trust decision. Every platform fails the same way when the controls fail: a workspace role that bypasses row-level security, an uncertified model feeding the board pack, a metric defined twice. All three vendors sell the pillars; none of them assigns your workspace roles, certifies your semantic model, or keeps the evidence chain. The firm that implements the controls is who builds reporting executives can trust.
How i3solutions Builds Reporting Executives Can Trust
The work is not a redesign; it is a set of disciplines applied in a defined order. Fix the workspace role assignment first: if RLS is meant to apply, the person is a Viewer. Everyone else is a documented exception. Certify the semantic model, not the dashboard, with one certified model, one owner, and one definition per metric. Use OLS where the column is the secret, and accept that it lives in Tabular Editor and in source control. Promote through deployment pipelines with Development, Test, and Production stages and item pairing, so a number never changes because someone edited production. Keep the evidence: impact analysis before a change, lineage after it, and a refresh history that reconciles.
The outcome we are aiming at is not a prettier dashboard. On a nuclear power operator, i3solutions replaced a manual reporting process with an automated dashboard that saved over $293,000 a year and, more importantly for the control environment, removed the manual reconciliation that had been the audit exposure. The saving was real. The reason the client cared was the reconciliation.
What This Costs
Custom Power BI dashboard development engagements at regulated enterprises typically range from $80,000 to $150,000 for a bounded project covering a single business area with a stable data source register, and from $300,000 to $750,000 for a multi-wave program covering enterprise-scale analytics capability with full governance, compliance evidence chains, and adoption work across multiple business units.
Enterprise reporting system design consulting engagements at i3solutions typically range from approximately $180,000 to $750,000 for the full three-phase engagement, with the range driven by five factors including data source complexity, governance scope, and adoption reach. Most engagements land at $300,000 to $450,000.
Who Does This Work
i3solutions has built enterprise reporting on the Microsoft stack for three decades, for organizations where a wrong number is a regulatory event rather than an embarrassment. Every engagement is senior-level and 100 percent US-based, delivered under the compliance standards regulated environments require.
Matt Lawson
Senior Consultant
Matt Lawson has spent more than 14 years at i3solutions guiding complex enterprise technology work from scope and system design through development, acceptance, and long-term support. His expertise spans technical oversight, solution architecture, SharePoint and Microsoft 365 delivery, Power Platform implementation, business intelligence, enterprise search, and the practical application of AI to solve real business and operational challenges.
A firm that treats executive trust as a controls problem rather than a design problem. i3solutions builds enterprise reporting for regulated organizations, starting from the controls an assessor will actually test: workspace role assignment (because Microsoft states row-level security does not apply to Admin, Member, or Contributor roles), certification of the semantic model rather than the dashboard, object-level security where a column is the secret, and deployment pipelines so a number never changes because someone edited production. Enterprise reporting system design consulting engagements at i3solutions typically range from approximately $180,000 to $750,000 for the full three-phase engagement, and most engagements land at $300,000 to $450,000.
Only from Viewers. Microsoft states that RLS only restricts data access for users with Viewer permissions and that it does not apply to workspace Admin, Member, or Contributor roles, because those roles carry edit permission on the semantic model. In most enterprises the analysts and BI team hold Contributor or Member so they can build, which means they see every row regardless of the RLS you designed. Microsoft's own remedy is blunt: if you want RLS to apply to someone in a workspace, you can only assign them the Viewer role. Two further traps: Microsoft 365 groups are not supported in RLS roles at all, and RLS roles are additive, so a user in two roles sees the union of both.
No. Microsoft is explicit: if a user has access to a particular row of data, they can see all the columns of data for that row. To restrict a column you need object-level security, which provides table-level and column-level security and also secures the metadata, so a user cannot discover that the object exists. Object-level security is not configured in the Power BI Desktop interface; it is set on the Roles object using Tabular Editor, TMSL, or TOM. Note also that row-level security and object-level security cannot be combined from different roles, which produces an error at query time.
Certification is one of three endorsement badges in Microsoft Fabric: Promoted, Certified, and Master data. Promoted can be applied by any user with write permissions, so it carries little assurance. Certified can only be applied by users a Fabric administrator specifies, although any user may request it, which is what makes it a real control. The critical limitation for executive reporting is that Power BI dashboards cannot be promoted or certified. Only the underlying items can be. If your board pack is a dashboard, the trust signal has to live on the certified semantic model beneath it, and your governance needs to say so.
It depends entirely on your capacity SKU. On Fabric capacities smaller than F64, every user who views Power BI content needs a Power BI Pro, Premium Per User, or trial license. On F64 or larger, users with only a free license and a Viewer role on the workspace can view content. Current Microsoft list pricing observed on 2026-07-12, paid yearly, is $14.00 per user per month for Power BI Pro and $24.00 per user per month for Premium Per User. F64 is therefore the real threshold for broad executive and frontline distribution, and the honest cost comparison is capacity versus per-seat licensing rather than a simple license count.
Almost always because there is more than one semantic model, or more than one definition of the metric inside one. The fix is structural: certify a single semantic model per subject area, give it a named owner, and promote changes through deployment pipelines (Development, Test, Production) so a number never changes because someone edited production directly. Then verify the blast radius before you change anything, using impact analysis rather than lineage view, because lineage shows the items in the workspace plus upstream sources one level up and does not show downstream items in other workspaces.
Not once it becomes a flat file. Sensitivity labels come from Microsoft Purview Information Protection and support manual, default, mandatory, and programmatic labeling with downstream inheritance, but Microsoft documents that access control does not survive export to .csv or .txt. Two further limits worth planning around: mandatory labeling is fully supported for Power BI items only, and downstream inheritance from a Power BI item to a Fabric item is not supported. Treat labels as a strong control inside the estate and as a weak one the moment a number leaves for a spreadsheet.
Trust the pillar each was built for, then staff the controls. Power BI holds metric logic in semantic models and DAX and is the value choice inside a Microsoft estate at $14.00 per user per month for Pro, per Microsoft's current published pricing. Tableau is trusted for visual verification, letting a leader drill from a KPI to the transactions behind it, with seat prices at $70, $42, and $15 per user per month for Creator, Explorer, and Viewer. Looker is trusted for metric governance through LookML, one governed definition per KPI. None of the three assigns workspace roles, certifies a semantic model, or keeps an evidence chain on its own; those controls decide whether executives trust the numbers, and implementing them is the work i3solutions does on the Microsoft stack for regulated organizations.
Governance Debt on the Power Platform Compounds Quietly
Ungoverned environments, unmanaged connectors, and apps on personal credentials surface at audits, not in demos. i3solutions' senior Power Platform advisors work with enterprise IT leaders who have found the exposure and want the remediation scoped.
