Business Intelligence¶

Scope¶

The consumption tier: the tools people actually open, and the architectural decisions that determine whether the platform underneath them delivers consistent answers. Covers the vendor landscape (Power BI, Tableau, Looker, Qlik, Strategy One — formerly MicroStrategy — and the open and embedded end: Apache Superset, Metabase, Streamlit); Power BI's per-user and capacity licensing model, which is frequently the hidden entry point to a much larger platform commitment; governed self-service versus centralised reporting and why self-service without a governed metric layer becomes uncontrolled; embedded analytics and multi-tenancy patterns; report sprawl, certification, usage telemetry and the retirement of dead content; and accessibility and dashboard performance as authoring disciplines rather than product features.

For metric definitions, headless semantic layers, and where row- and column-level security should be enforced, see general/semantic-layer.md — that file carries the enforcement argument and this one does not repeat it. For catalog, certification and endorsement tiers, lineage, and the per-engine policy matrix, see general/data-governance.md. For Microsoft Fabric platform detail — OneLake, capacity units, smoothing, bursting, throttling, Direct Lake storage modes and their fallback conditions — see providers/azure/fabric.md; this file covers Power BI as a BI tool and its licensing, and cross-links rather than duplicating. For platform selection across the whole stack, see patterns/data-platform-selection.md.

A note on what this file does not contain. No market-share, revenue, seat-count, or "leader quadrant" figures appear here. Those numbers circulate widely, are almost never traceable to primary documentation, and decay faster than the products do. Where a licensing or capability claim is made below it is sourced to the vendor's own current documentation and dated; where a figure could not be sourced that way it has been omitted rather than approximated.

Checklist¶

Tool Selection and the Vendor Landscape¶

[Critical] Has the BI tool decision been recognised as a platform decision rather than a front-end decision where the vendor's BI product is the entry point to a data platform? This is most acute with Power BI and Fabric, and it also applies to Looker within Google Cloud and to Tableau's data-management add-ons. The tool gets chosen on demo quality and user familiarity; the commitment that follows is capacity, storage, governance tooling, and a security model. Evaluate what the estate looks like three years after the tool is adopted, not what the first report costs.
[Critical] Is the tool's modelling and semantics story evaluated alongside its visualisation story? Every one of these products carries an opinion about where metric logic lives, and that opinion outlasts any visual preference. Power BI has semantic models expressed in DAX; Looker has LookML held in Git and compiled to SQL; Qlik builds an in-memory application from a load script; Tableau has data sources, calculated fields, and — with its Data Management licence — virtual connections carrying server-enforced data policies; Superset has what its documentation calls a "lightweight semantic layer for quickly defining custom dimensions and metrics". These are not interchangeable, and a tool whose model cannot express the organisation's metrics will be worked around by every author.
[Critical] Is the data-access pattern understood — does the tool query the source, or does it take a copy? Power BI's Import mode, Tableau extracts, and Qlik's in-memory apps all create a second copy of the data with its own refresh schedule, its own storage, and — critically — its own security surface, because the source system's roles are not carried into the copy. Live/DirectQuery/pushdown modes avoid the copy at the cost of pushing every interaction to the engine. The choice determines refresh architecture, cost model, and the erasure and access-review scope. general/semantic-layer.md covers the security consequence; providers/azure/fabric.md covers the Power BI storage modes and Direct Lake fallback in detail.
[Critical] Has the number of BI tools the organisation will actually run been decided, rather than allowed to accumulate? Two tools is a common and sometimes correct outcome — an enterprise standard plus a specialist or embedded product. Two tools with no shared metric layer is the configuration that guarantees inconsistent numbers, and it is reached by drift rather than by decision. If two tools are the answer, a tool-independent semantic layer moves from optional to load-bearing.
[Recommended] For the open-source and embedded end, is the distinction between the categories clear? Apache Superset is a full BI platform under the Apache Software Foundation with datasets, charts, dashboards, SQL Lab, a caching layer, and row-level security implemented by injecting a clause into the generated WHERE. Metabase targets self-service question-asking with a lower authoring bar; its row and column security is a paid-tier feature and it documents plainly that "groups with native query permissions (access to the SQL editor) can bypass row and column security." Streamlit is not a BI tool — it is a Python framework for building bespoke data applications, and it belongs in this conversation only because it is frequently and reasonably chosen instead of a BI tool when the requirement is a purpose-built interactive tool rather than a report. Treating it as a BI substitute produces an estate of unmaintained one-off apps with no shared semantics; treating it as an application framework is correct.
[Recommended] Is Strategy One (formerly MicroStrategy ONE; the vendor completed its legal name change from MicroStrategy Incorporated to Strategy Inc in August 2025) evaluated on the same terms as the others rather than dismissed as legacy or retained by inertia? Its historical strengths — enterprise-scale semantic modelling and large governed deployments — are real, and so is the fact that a name change signals a corporate strategy in which the analytics product is one of two very different businesses. That is a legitimate vendor-viability input for a ten-year platform decision, and patterns/data-platform-selection.md covers how to weigh concentration and exit risk generally.
[Recommended] Is the security enforcement model of the candidate tool examined before selection rather than after? The products differ materially and each documents its own limits: Power BI's RLS and object-level security apply only to workspace Viewers; Tableau distinguishes user filters (removable by anyone who can download the workbook) from virtual-connection data policies enforced server-side "for every query"; Qlik reduces data in the load script through section access, hiding columns with OMIT; Superset enforces RLS in SQL Lab only when a feature flag is set. These are architectural facts, not feature-list details, and they constrain what the tool can be trusted with.
[Optional] Has the availability of skills in the local market been weighted honestly against product capability? A tool the organisation cannot hire for is a tool whose model degrades. This favours the widely-adopted products for the enterprise standard and argues for keeping specialist tools scoped to the specialists.

Power BI Licensing and Capacity¶

Verified against Microsoft documentation on 2026-07-26. Licensing and SKU structure is the fastest-decaying content in this file and has changed repeatedly. Re-verify before quoting any of it in a decision document. Sources: Power BI service features by license type (Microsoft-stated article date 2025-09-30) and Microsoft Fabric licenses (Microsoft-stated article date 2026-06-15).

[Critical] Is the two-axis structure understood — a per-user licence and a capacity, both of which are required for most real deployments? Microsoft documents three per-user types: Fabric (Free), Power BI Pro, and Power BI Premium Per User (PPU); plus capacity subscriptions (Fabric F SKUs, and the Power BI Premium P SKUs now being retired). What a given user can do is the combination, not either one alone. Free users "can use the Power BI service to connect to data and create reports and dashboards for their own use" but "can't use the Power BI sharing or collaborating features with others". Pro "lets users create, read, and interact with content that others publish", sharing with other Pro users. PPU "provides all Power BI Pro capabilities plus most Premium capacity features", with sharing limited to other PPU users unless the content sits on Premium capacity.
[Critical] Is the F64 threshold treated as the dominant sizing input for any broad-audience reporting estate? Microsoft states it directly: "On F SKUs smaller than F64, each user viewing Power BI content must have Pro, PPU, or an individual trial. On F64 or larger, users with only a Free license and a viewer role can view Power BI content." For an organisation with a few dozen authors and a few thousand readers, the reader licence arithmetic swamps the compute arithmetic, and the correct capacity size is determined by the audience rather than by the workload. Authors and editors need Pro or PPU regardless of capacity size.
[Critical] Is it understood that PPU does not provision a Fabric capacity? Microsoft's statement is unambiguous and bolded in its own documentation: "Premium Per User (PPU) doesn't provision a Fabric capacity. Although PPU provides access to most Power BI Premium features, it doesn't enable you to create or run non-Power BI Fabric items (such as lakehouses, warehouses, or notebooks). To use Fabric workloads beyond Power BI, you need an F capacity or a Trial Fabric capacity." A plan that reaches Fabric workloads by buying PPU licences does not work, at any number of licences. Microsoft separately notes PPU "is more cost effective when Power BI Premium features are needed for fewer than 250 users" — a useful vendor-stated crossover point, though it addresses Power BI features only and says nothing about Fabric.
[Critical] If the organisation already holds Power BI Premium P-SKU capacity, has it been checked before Fabric is treated as a new purchase — and is the enablement caveat known? P SKUs support Fabric, but Microsoft documents that "if you're using a Power BI Premium capacity, Microsoft Fabric items aren't enabled. To enable support for Microsoft Fabric items on your Power BI capacity, enable Microsoft Fabric" — a Fabric admin must switch it on. Note also that A and EM SKUs support Power BI items only. Microsoft is "consolidating purchase options and retiring the Power BI Premium per-capacity SKUs" and advises that "new and existing customers should consider purchasing Fabric capacity subscriptions (F SKUs) instead"; the retirement timeline and wind-down behaviour are covered in providers/azure/fabric.md.
[Critical] Has the entry-point dynamic been named explicitly in the decision record? The common sequence is: a department buys Pro licences for a reporting need; the audience grows and per-viewer licensing becomes the dominant cost; F64 becomes the economical answer; F64 is a Fabric capacity; the organisation now owns a data platform it never evaluated as one, with its governance, security, and residency implications arriving after the fact. There is nothing wrong with the destination — but arriving at it through licence arithmetic rather than through a platform decision means the platform questions in patterns/data-platform-selection.md were never asked.
[Recommended] Are published list prices treated as an order-of-magnitude input rather than a quotable figure? As published on Microsoft's Power BI pricing page and read on 2026-07-26, Power BI Pro is listed at $14.00 user/month, paid yearly and Power BI Premium Per User at $24.00 user/month, paid yearly, with Fabric capacity shown as "Variable" for both reservation and pay-as-you-go. Microsoft's own page carries the disclaimer that "prices shown are for marketing purposes only and may not be reflective of actual list price due to currency, country, and regional variant factors." Use them to establish that PPU is under twice Pro and that the F64 break-even is computable; do not put them in a business case without re-verifying and without an enterprise-agreement discount assumption.
[Recommended] Is the capacity consumption model — not just the SKU price — in the cost model? Fabric capacity bills on capacity units with smoothing, bursting, and throttling behaviour that determines what actually happens when the estate exceeds its size, and F SKUs can be paused. All of that mechanism lives in providers/azure/fabric.md and it materially changes the economics of a bursty reporting workload relative to a naive "SKU price × 12" calculation.
[Recommended] Has the licensing consequence of the consumption path been checked for each integration? Analyse in Excel, the XMLA endpoint, embedded scenarios, and API access each carry their own licence and capacity requirements, and a design that assumes "the model is reachable from anywhere" usually assumes a licence somebody has not bought.
[Optional] Is there a periodic reconciliation of assigned licences against actual usage? Pro licences assigned to users who only ever view content in an F64+ workspace are pure waste, and they accumulate through joiners-and-leavers drift rather than through any decision.

Governed Self-Service Versus Centralised Reporting¶

[Critical] Is the position on the self-service spectrum an explicit decision with a named operating model, rather than a default? Fully centralised reporting is consistent, auditable, and a bottleneck that produces shadow spreadsheets. Fully devolved self-service is fast, popular, and produces contradictory numbers within a year. The workable arrangement — governed self-service — is a specific division of labour, and it has to be written down: a central team owns the gold-layer tables and the certified semantic models; authors build reports against those models; authoring directly against raw sources is the controlled exception rather than the default path.
[Critical] Is it understood that "self-service" without a governed metric layer is not self-service but uncontrolled redefinition? If every author connects to sources and builds their own model, then every author has authored a metric definition, whether or not they knew they were doing it. The tool's ease of use is what makes this happen quickly and at scale — a hundred people can each define revenue in an afternoon. The counter is not to restrict the tool; it is to make the governed model the path of least resistance. general/semantic-layer.md covers why that failure recurs and what actually prevents it.
[Critical] Is there a technical control, not just a policy, over which authors may create their own connections to underlying sources? A policy that says "build against the certified model" with no enforcement is a suggestion, and it loses to a deadline every time. The controls available differ per product — connection permissions, gateway restrictions, source-level grants that simply do not include the report-author population — but some control is needed, and choosing to have none is a legitimate decision that should be recorded as such.
[Critical] Is the distinction between authoring capability and modelling competence built into the enablement plan? Dragging fields onto a canvas is easy; reasoning about grain, filter context, additivity, and relationship cardinality is not, and no amount of tool training conveys it. The predictable outcome of enabling authors without teaching modelling is a population of confident authors producing plausible wrong numbers — see general/data-modelling.md for the specific defects, all of which are reachable from a BI tool's modelling pane. Certify a smaller number of people to build models than to build reports.
[Recommended] Is there a support and escalation path for self-service authors, with someone accountable for it? Devolving authoring without devolving support means the central team receives the same volume of work as before, now arriving as unpredictable interruptions rather than as a backlog. A community of practice, an office-hours slot, and a named channel are the cheap version and they materially change adoption quality.
[Recommended] Are workspace and app structures designed as the primary organising control rather than left to emerge? A small number of governed workspaces aligned to domains, with apps as the distribution mechanism to consumers, is the arrangement that keeps content findable and permissions reviewable. A workspace per person is the arrangement that produces sprawl, and it is what happens by default.
[Recommended] Is the difference between certified content and personal content visible to consumers at the moment they choose what to open? This is the practical purpose of endorsement tiers, and general/data-governance.md covers the Promoted / Certified / Master data model, who may grant each, and the point that self-service certification asserts nothing. The BI-specific addition is that the badge has to be visible in the browse experience the consumers actually use, not only in the catalog they never visit.
[Optional] Is there a defined promotion path from personal exploration to certified content? Without one, good analysis stays personal (and gets rebuilt repeatedly) or gets certified informally by becoming widely used. Both are worse than a stated route with a review step.

Embedded Analytics and Multi-Tenancy¶

[Critical] Is the embedding model chosen deliberately between app-owns-data and user-owns-data, given that they have entirely different licensing and identity consequences? Microsoft documents the two as "embed for your customers" and "embed for your organization". For embed-for-your-customers (app owns data): "aimed at external users", "to authenticate app users, use your own authentication method", "app users don't need a license", and "your app uses a service principal or a master user to authenticate". For embed-for-your-organization (user owns data): "aimed at internal users", "app users authenticate against Microsoft Entra ID", and "each app user needs a Power BI license". Choosing the wrong one is not a configuration change; it is a different identity architecture.
[Critical] Is it understood that per-user row filtering does not work automatically under a service principal, and that the embedded path requires an explicit identity mechanism? Power BI states that "service principals can't be added to an RLS role. Accordingly, RLS isn't applied for apps using a service principal as the final effective identity", and that in service-principal embedding USERPRINCIPALNAME() and USERNAME() "return the service principal's application ID or an empty string—not an end user's identity." Per-user filtering in that mode requires passing an EffectiveIdentity (and CustomData where the rules use CUSTOMDATA()) when generating the embed token. This is the single most common defect in multi-tenant embedded analytics, and it fails open: the application works, the reports render, and every tenant sees every tenant's rows until someone notices.
[Critical] Is the multi-tenancy isolation model chosen against the actual requirement rather than against convenience? Workspace (or capacity) per tenant gives genuine object-level isolation, per-tenant customisation, clean cost attribution, and independent refresh — at the cost of an item count and an onboarding automation burden that grows linearly with tenants. A single shared workspace with row-level filtering scales to many tenants cheaply and makes every tenant's data co-resident in one model, so the filter is the only thing separating them. If the contractual or regulatory requirement is that tenant data is not co-resident, filtering does not satisfy it and no amount of testing will make it satisfy it.
[Critical] Has it been established that production embedding requires purchased capacity? Microsoft is explicit: "Free trial tokens are limited to development testing only. For production, a capacity must be purchased. Until a capacity is purchased, the Free trial version banner continues to appear at the top of the embedded report." A proof of concept that works on trial tokens has not demonstrated the production cost.
[Recommended] Is the capacity SKU family right for the embedding scenario? Microsoft documents three offers carrying different SKUs — Power BI Embedded (Azure, A SKUs, associated with embed-for-your-customers), Power BI Premium (P or EM SKUs), and Microsoft Fabric (F SKUs) — and notes that for embed-for-your-organization and embedding in Microsoft 365 apps, "F SKUs smaller than F64 and all A SKUs require each consuming user to have a Pro, Premium Per User (PPU), or individual trial license to view Power BI content." The F64 threshold reappears in the embedded context and is easy to miss when sizing.
[Recommended] Is per-tenant cost attribution designed in, given that capacity is a shared pool? Without it, one heavy tenant is invisible until the capacity throttles, and there is no basis for tiered pricing or for a conversation with the tenant. Usage telemetry by tenant is the input; the capacity metrics behaviour that makes throttling happen is in providers/azure/fabric.md.
[Recommended] Are feature limitations of the chosen embedding mode checked against the report designs before build? Microsoft notes, for example, that R and Python visuals "are not supported" in embed-for-your-customers but are supported in embed-for-your-organization. Discovering a mode-specific limitation after the reports are built is a rework of the reports, not of the embedding.
[Optional] Is the simplest option — secure embed via URL or iFrame — evaluated before an SDK integration? Microsoft describes it as "the simplest no-code way to embed a report into any portal that accepts a URL or iFrame", with the constraint that "the viewer of the report must have the proper Power BI license." For internal portals with licensed users it removes an entire integration workstream.

Report Sprawl, Certification, Telemetry, and Retirement¶

[Critical] Is it recognised that publishing is free and deleting is nobody's job, and that this asymmetry is the whole mechanism of report sprawl? Every report has an author with an incentive to create it and no one with an incentive to remove it. Left alone, an estate accumulates hundreds of reports of which a minority are used, each one a maintenance liability when a source changes, an inconsistency source when it disagrees with its successor, and an item in the erasure and access-review scope. The fix is not tidier authoring; it is a lifecycle with a named owner and a schedule.
[Critical] Is there a certification or endorsement mechanism in use, with certification authority restricted rather than self-service? general/data-governance.md covers the tiers, who may grant each, the standing obligation certification creates, and the fact that decertification is silent unless consumers are actively notified. The BI-layer point is narrower: certification only does work if the badge is visible where consumers choose content and if an uncertified report is visibly uncertified rather than merely un-badged.
[Critical] Is usage telemetry captured and retained beyond the platform's own window? This is where the Power BI specifics matter most, and Microsoft states the constraint plainly: "The Usage Metrics Report semantic model contains usage data for the last 30 days only. Data older than 30 days is automatically removed"; and "to preserve historical data beyond 30 days, you need to export the data periodically to an external data store." Thirty days cannot answer "is this quarterly board report used" — the report is opened four times a year. An estate that has not set up telemetry export cannot make evidence-based retirement decisions about anything with a cycle longer than a month, and that is exactly the content most likely to be both important and stale.
[Critical] Are the known gaps in usage telemetry understood before decisions are based on it? Microsoft documents that Report View metrics come from service activity data and match audit-log aggregates, while "Report Page Views rely on client telemetry and can be affected by undercounting and overcounting of activities due to inconsistent network connections, ad blockers, or other client-side issues." It also notes that where Azure Private Link is in use "the reporting might not work", that report performance metrics are unavailable for paginated reports, and that deleted-and-recreated reports and app-embedded copies produce duplicate entries. Retiring a report on the basis of an undercount is a self-inflicted incident.
[Recommended] Are the access requirements for telemetry built into the operating model rather than discovered? Microsoft documents that running usage metrics requires a Pro or PPU licence, that "only users with admin, member, or contributor permissions can view the usage metrics report — Viewer permissions aren't enough", and that a tenant admin must have enabled the feature. If the person accountable for content lifecycle is not a workspace contributor, they cannot see the data they are accountable for acting on.
[Recommended] Is the per-user visibility setting decided deliberately, given the privacy trade? Per-user data is enabled by default and includes consumer account information; admins can disable it organisation-wide or per security group, after which the report shows "Unnamed User". Disabling it makes "who still uses this" unanswerable at the individual level — a real cost — and there is a documented gap where "user masking isn't working as expected when using nested groups". Decide, record the decision, and verify the masking behaves as expected against your group structure.
[Recommended] Is retirement a defined sequence rather than an occasional purge? The one that works: identify candidates from telemetry (Power BI's usage metrics surfaces an explicit "unused reports" count) → confirm with the named owner → mark deprecated with an end date, in the report itself where consumers will see it → remove from the distributing app so it stops being discoverable → archive the definition to source control → delete. Skipping the archive step is what makes people afraid to delete, which is what makes the purge never happen.
[Recommended] Is report and semantic-model definition held in source control? Beyond the retirement-confidence point, it is what makes review, diffing, and rollback possible, and it is the precondition for treating metric definitions as versioned artefacts at all (general/semantic-layer.md).
[Optional] Is there a cap or a review trigger on the number of reports per workspace or per app? A soft limit that forces a conversation is more effective than an annual cleanup, because it applies pressure at creation time when the alternative — extending an existing report — is still cheap.

Accessibility¶

[Critical] Is accessibility treated as an authoring discipline supported by product capability, rather than as a product feature that is either present or absent? Microsoft states the division of responsibility exactly: "Power BI provides the capability to create accessible reports, but as the report author, it's up to you to incorporate that capability into your reports." Keyboard navigation, screen-reader compatibility, high-contrast detection, focus mode, and the screen-reader-friendly data table are built in; alt text, tab order, markers, titles, and colour choices are the author's job and are not done by default.
[Critical] Is a conformance target named — normally WCAG 2.2 at Level AA — and is it in the authoring standard rather than only in the procurement response? WCAG 2.2 is a W3C Recommendation published 12 December 2024, organised under four principles (perceivable, operable, understandable, robust) with conformance levels A, AA, and AAA. Public-sector procurement and a growing share of enterprise procurement require a conformance statement, and a statement that the tool is accessible says nothing about whether the reports are.
[Critical] Is the contrast requirement applied to report content, not just to the product chrome? Microsoft's guidance for Power BI authors cites the WCAG success criterion directly: "text and background color should have a contrast ratio of at least 4.5:1", applied to "title, axis label, and data label text". Corporate palettes routinely fail this, and a palette adopted for brand reasons will silently make every report non-conformant until it is checked.
[Critical] Is colour prohibited as the sole carrier of information? Microsoft's instruction is explicit — "avoid using color (including features conditional formatting) as the only way of conveying information. Instead, use markers to convey different series" — with a documented list of combinations that are difficult to distinguish (green/red, green/brown, blue/purple, green/blue, light green/yellow, blue/grey, green/grey, green/black). This is the single highest-yield authoring rule and the one most consistently ignored, because a status column of red and green dots looks obviously clear to the person who built it.
[Recommended] Is alt text required on every non-decorative visual, and are decorative elements removed from the tab order? Microsoft's guidance is that authors "should add alt text to every object that conveys meaningful information on a report", that the alt-text field has a 250-character limit, and that decorative shapes and images should be hidden from the tab order so screen readers do not announce them. Alt text can be made dynamic with DAX and conditional formatting where a static description would be misleading.
[Recommended] Is tab order set deliberately on every page rather than left as the creation order of the objects? Default tab order follows the sequence in which the author dropped elements onto the canvas, which bears no relationship to how the page reads.
[Recommended] Are tooltips excluded from carrying essential information? Microsoft is direct: "don't use tooltips to convey important information. Users with motor problems and users who don't use a mouse have difficulties accessing them." The same reasoning applies to hover-only interactions and to insights that are only reachable through a cross-filter.
[Optional] Is there an accessibility review step in the publishing process, using the vendor's own checklist? Power BI ships a report accessibility checklist covering visuals, slicers, textboxes, interactions, sort order, tooltips, video, audio, shapes, and images. A five-minute pass against a checklist at publish time is worth more than a remediation programme.

Dashboard Performance¶

[Critical] Is the semantic model treated as the primary performance lever rather than the visuals? Microsoft's optimisation guidance puts it first — "the data model supports the entire visualization experience" and "the semantic model is the foundation of all reporting in Power BI" — and in practice most report-level performance problems are model problems: excessive cardinality, unnecessary columns retained, relationships that force expensive filter propagation, and measures that scan more than they need. Tuning visuals on a bad model is rearranging the symptom.
[Critical] Is it understood that row-level security multiplies cached query volume? Microsoft documents that Power BI caches dashboard tiles, that "if your semantic model enforces dynamic row-level security (RLS)… tiles will cache on a per-user basis", and that during cache refresh for DirectQuery and live-connection models "if row-level security is enabled, queries are generated for each different security context". A design that adds dynamic RLS to a widely-consumed dashboard has changed the refresh cost by a factor of the distinct security-context count, and that is discovered as a throttling incident rather than as a design review finding.
[Critical] Are visuals filtered to what is needed rather than defaulting to the full table? Microsoft's worked example is the common one: a table left unfiltered against a 100M-row model, where "the data for these rows loads into memory and is uncompressed at every refresh", fixed with a Top N filter set well above what any user needs. The end-user experience is unchanged and the memory profile is transformed. Apply the question — is all the data in this visual needed? — per visual.
[Recommended] Is the number of visuals per page constrained? Microsoft recommends limiting visuals "to only what is necessary" and points to drillthrough pages and report page tooltips as the way to provide detail without adding visuals — but publishes no specific maximum, and no such number is quoted here because none is sourced. Measure the page rather than counting the visuals.
[Recommended] Are custom and third-party visuals performance-tested before adoption? Microsoft's warning is that "poorly optimized Power BI visuals can negatively affect the performance of the entire report" — a single bad visual is not a localised problem. This is also a supply-chain question: a third-party visual is code running in the report.
[Recommended] Is performance measured against the interaction pattern rather than a single load? Power BI's usage metrics report exposes typical opening time as the 50th percentile of report-open duration, broken down by consumption method and browser, plus 25th/50th/75th percentile daily and seven-day series. Note its documented boundary: it measures "the initial report load and first page viewed", and "report interactions such as slicing, filtering, or changing pages aren't included in performance metrics" — so the slicer that fires a dozen queries is invisible to it and needs testing in Performance Analyzer at design time.
[Recommended] Are the environment factors in scope — gateway sizing, region colocation, and network latency? Microsoft's guidance is to "keep data sources, gateways, and your Power BI capacity as close as possible", preferably in the same region. A gateway sized for a proof of concept is a common and invisible bottleneck once the estate is real.
[Optional] Is dashboard tile caching used deliberately as a performance strategy? Microsoft suggests making dashboards the first landing page so cached tiles act as "a valuable 'first line of defense', which delivers consistent performance with less load on the capacity", with the caveat that live report tiles "are not served from the query cache" and behave like reports.

Why This Matters¶

Every layer below the BI tool is invisible to the people the platform was built for. The warehouse, the table format, the orchestration, the catalog — none of it is ever seen by the executive who opens a report on a phone. The consumption layer is the entire product as far as the organisation is concerned, and its output is the only evidence most people will ever have about whether the platform works. This is why an ungoverned BI tier defeats a governed platform underneath it: the numbers are still inconsistent, and consistency was the deliverable.

Power BI licensing deserves the attention it gets because it is where a tool decision quietly becomes a platform decision. The sequence is unremarkable at every step. A team needs reports and buys Pro licences. The audience grows, and per-viewer Pro licensing starts to dominate the bill. Someone computes that F64 is cheaper than the reader licences it replaces, which is often true. F64 is a Fabric capacity, so the organisation now owns a data platform — with its own governance model, security model, residency characteristics, and vendor concentration — acquired through a licensing calculation rather than through the evaluation in patterns/data-platform-selection.md. The destination can be entirely correct. Arriving there without having asked the platform questions is what produces the retrofit programme two years later. The two facts most often got wrong in this arithmetic are that Premium Per User provisions no Fabric capacity at all, so no quantity of PPU licences reaches Fabric workloads; and that a Power BI Premium capacity does not have Fabric items enabled by default, so an organisation can own the capacity, believe it owns Fabric, and be wrong.

Self-service is the second place where an unstated decision becomes an expensive one. The pitch is that analysts answer their own questions instead of queuing for a central team, and it works — that part is real. What is left implicit is that an author who builds their own model has authored a metric definition, and that the tools are good enough that a hundred people can do this in an afternoon. The failure is not that anyone did anything wrong; it is that the organisation devolved authoring without devolving the definition, and definitions cannot be devolved without forking. Governed self-service is the arrangement that keeps the benefit: the central team owns the certified models, authors own the reports, and building against raw sources is an exception with a name on it. Getting there requires a technical control and not only a policy, because a policy without enforcement loses to a deadline.

Embedded multi-tenancy is where the failure mode is worst, because it fails open and silently. A service principal authenticates the application, the reports render, the tenants are happy, and dynamic row-level security based on the signed-in user's identity does nothing at all — because there is no signed-in user, and the functions those rules depend on return the application's identity or an empty string. Nothing errors. The correct mechanism (passing an effective identity with the embed token) exists and is documented, but it must be chosen, and a design that assumes the model's RLS "just works" will ship a cross-tenant data exposure that looks like a working product. Any embedded deployment should be tested by signing in as two tenants and comparing what they see, before launch and after every change to the model.

Sprawl, accessibility, and performance share a structural property: each is caused by an asymmetry of effort, and each is therefore fixed by process rather than by tooling. Publishing costs a click and deleting costs a conversation, so reports accumulate. Adding a visual costs a drag and adding alt text costs a thought, so alt text is missing. Making a page richer is visible to the author and making it fast is not, so pages get slow. In every case the product provides the capability and the default behaviour is the wrong one. And in the specific case of retirement there is a hard technical constraint that catches organisations out: Power BI retains thirty days of usage data and deletes the rest, so an estate that has not built a telemetry export cannot make an evidence-based decision about any report with a cycle longer than a month — which is precisely the population of quarterly and annual reports where the stale content hides.

Common Decisions (ADR Triggers)¶

ADR: Enterprise BI Tool Selection¶

Context: The organisation is standardising on a BI platform, or deciding whether to add a second.

Criterion	Power BI	Tableau	Looker	Qlik	Strategy One
Modelling artefact	Semantic model (DAX)	Data sources, calculated fields, virtual connections	LookML in Git, compiled to SQL	In-memory app built by a load script	Enterprise semantic layer
Default data access	Import, DirectQuery, Direct Lake	Extract or live	Generates SQL against the warehouse	In-memory application	Warehouse query with caching
Server-enforced row security	RLS roles (Viewers only)	Data policies on virtual connections (Data Management licence)	Access filters via user attributes	Section access in the load script	Enterprise security filters
Licensing shape	Per-user plus capacity	Role-based per user	Platform plus users	Per user / capacity	Enterprise agreement
Platform entanglement	High — capacity is Fabric	Moderate — Salesforce ecosystem	Moderate — Google Cloud	Low	Low
Distinctive strength	Microsoft-estate integration and reach	Visual analysis and analyst experience	Git-versioned model, single SQL path	Associative in-memory exploration	Large governed enterprise deployments

Decision drivers: the existing cloud and productivity estate (which usually dominates), whether the modelling artefact suits how the organisation wants to govern metrics, whether a copy of the data is acceptable, the licensing shape against the author-to-reader ratio, and how much platform commitment the BI choice drags with it. Where the answer is Power BI, evaluate the Fabric platform question explicitly rather than inheriting it.

ADR: Power BI Capacity Sizing and Licence Mix¶

Context: A Power BI estate must be sized, and the trade is between per-user licences and capacity.

Options: Pro/PPU licences for everyone with no capacity (simplest; cost scales linearly with the audience; no Fabric workloads); an F SKU below F64 (capacity for workloads, but every viewer still needs Pro or PPU); F64 or larger (Fabric Free viewers with the Viewer role can consume, which is usually the breakpoint for a large reader population); or continuing on existing P-SKU Premium capacity until the agreement term ends, with Fabric explicitly enabled if Fabric items are needed.

Decision drivers: the reader count above all — the licence arithmetic usually dominates the compute arithmetic; whether non-Power BI Fabric workloads are in scope (PPU cannot provide them at any quantity); whether P-SKU capacity is already owned; and the workload's burstiness against the capacity consumption model in providers/azure/fabric.md. Re-verify the SKU structure at decision time — this content changes.

ADR: Embedded Analytics Identity Model¶

Context: Analytics must be embedded in an application, and the identity and licensing model must be chosen.

Options: embed for your organization (user owns data) — Entra authentication, each user licensed, per-user RLS works naturally from the signed-in identity; embed for your customers (app owns data) — your own authentication, no end-user licences, service principal or master user, and per-user filtering only via an effective identity passed with the embed token; or secure embed by URL/iFrame where the audience is already licensed.

Decision drivers: whether consumers are internal or external; whether they can hold a licence at all; whether per-user or per-tenant filtering is required; and whether the required visual types are supported in the chosen mode. The identity mechanism is the load-bearing part — record explicitly how per-tenant filtering is enforced and how it is tested.

ADR: Multi-Tenant Isolation for Embedded Reporting¶

Context: One reporting application serves many customer tenants.

Options: workspace (or capacity) per tenant — real object isolation, per-tenant customisation, clean cost attribution, linear onboarding and item-count cost; single workspace with row-level filtering — cheap to scale, co-resident data, and the filter is the only separation; or a hybrid where large or regulated tenants get their own workspace and the long tail is filtered.

Decision drivers: whether the contract or regulation prohibits co-residency (if so, filtering is not an option regardless of how well it is implemented); tenant count and onboarding automation maturity; per-tenant customisation requirements; noisy-neighbour tolerance; and whether cost must be attributed per tenant. The hybrid is common and should be designed for from the start rather than reached by exception.

ADR: Self-Service Governance Model¶

Context: The organisation must decide who may build models, who may build reports, and against what.

Options: centralised — one team builds everything, consistent and a bottleneck; governed self-service — central team owns gold tables and certified models, authors build reports against them, direct source access is a controlled exception; or open self-service — anyone connects to anything, fast and forking.

Decision drivers: central team capacity against demand; whether a technical control over source connections exists or can be built; the availability of modelling competence in the author population; certification authority and who staffs the review; and whether the organisation can tolerate the interval during which two teams produce two numbers. Choosing not to decide selects open self-service.

ADR: Content Lifecycle and Retirement Policy¶

Context: The report estate is growing and nothing is ever removed.

Options: no policy — sprawl continues, and every source change becomes a larger regression surface; periodic manual review — better, and reliably deprioritised; or telemetry-driven lifecycle — usage exported beyond the platform's retention window, unused content flagged automatically, owner confirmation, deprecation window, archive to source control, delete.

Decision drivers: whether usage telemetry is being exported at all (without it, only content with a sub-monthly cycle can be judged); who owns the lifecycle and whether they hold the permissions needed to see the telemetry; whether report definitions are in source control so deletion is reversible; and the tolerance for the deprecation window's duration. The archive step is what makes deletion politically possible.

Reference Architectures¶

Microsoft-estate standard — gold tables in the lakehouse or warehouse → a small number of certified Power BI semantic models owned centrally → reports authored by domain analysts against those models only → distribution through apps to a Fabric Free viewer population on an F64 or larger capacity. Security enforced in the engine where identity propagates, with model RLS as a second layer, and endorsement badges distinguishing certified from personal content. The F64 threshold, not the workload, sets the capacity size.
Multi-tool estate with a shared metric layer — an enterprise BI standard plus a specialist or embedded product, both querying a tool-independent semantic layer that holds the governed metric definitions (general/semantic-layer.md). Each tool's native modelling is constrained by policy and, where possible, by connection permissions. Without that constraint the arrangement degrades into two definition stores plus the cost of the layer.
Embedded multi-tenant SaaS — app-owns-data embedding with a service principal, per-tenant filtering enforced by passing an effective identity with each embed token, tenant isolation by workspace for large or regulated tenants and by row filtering for the long tail, capacity sized from aggregate tenant load with per-tenant usage attributed from telemetry, and a pre-release test that signs in as two tenants and diffs what they see.
Open-source consumption tier — Superset or Metabase over a governed warehouse, with security enforced by warehouse-native row and column policies rather than by the BI tool, because both products document paths by which their own filtering is bypassed (Superset's SQL Lab behind a feature flag; Metabase's SQL editor by design). Appropriate where the estate wants no per-viewer licence cost and can staff the operational burden; the security posture must be warehouse-first.
Governed self-service operating model — a certified-model catalogue with named owners; an author certification separate from a viewer role and stricter than it; a technical control on who may create source connections; a community-of-practice support channel; endorsement badges visible in the browse experience; usage telemetry exported nightly to a durable store; and a quarterly retirement pass driven from that store. Each element is cheap; the combination is what stops the estate from forking.

Reference Links¶

Power BI service features by license type -- Free, Pro, and PPU capabilities and the shared-versus-Premium-capacity distinction
Microsoft Fabric licenses -- F SKU table, P/A/EM equivalence, the F64 viewing threshold, and the PPU-provisions-no-capacity statement
Power BI pricing (Microsoft) -- published per-user list prices, with Microsoft's own accuracy disclaimer
Power BI embedded analytics overview -- app-owns-data versus user-owns-data, secure embed, and the production-capacity requirement
Capacity and SKUs in Power BI embedded analytics -- A, EM, P, and F SKU behaviour for embedding
Row-level security with Power BI -- DAX roles, the Viewer-only limitation, service-principal behaviour, and effective identity for embedding
Object-level security with Power BI -- table and column restriction, and the broken-visual failure mode
Optimization guide for Power BI -- model-first optimisation, dashboard tile caching under RLS, filter and visual-count guidance, gateway and latency
Monitor usage metrics in Power BI workspaces -- 30-day retention, permissions, per-user masking, unused-report counts, and the client-telemetry caveats
Design Power BI reports for accessibility -- alt text, tab order, markers, the 4.5:1 contrast requirement, and the report accessibility checklist
Power BI implementation planning -- Microsoft's adoption, governance, and tenant-setup guidance series
Fabric workspace monitoring -- operational telemetry for workspaces and their items
Permissions, site roles, and licenses (Tableau) -- Creator, Explorer, and Viewer roles and what each licence permits
Row-level security options (Tableau) -- user filters versus server-enforced data policies, and the download-removes-the-filter warning
Virtual connections overview (Tableau) -- centralised connections carrying data policies, and the Data Management licence requirement
Looker documentation -- the platform overview and the LookML-modelled query path
What is LookML? -- Looker's Git-versioned modelling language
Looker access control and permission management -- roles, model sets, and access filters
Qlik section access -- load-script data reduction, the OMIT field, the uppercase requirement, and the optimised-QVD caveat
Qlik Cloud Analytics -- vendor product overview (marketing page, not documentation)
Strategy One readme -- current release documentation for the platform formerly named MicroStrategy ONE
Strategy legal name change announcement -- the August 2025 change from MicroStrategy Incorporated to Strategy Inc
Apache Superset -- the open-source BI platform project
Apache Superset user documentation -- capabilities including the lightweight semantic layer and caching layer
Apache Superset security -- roles, row-level security clause injection, and the RLS_IN_SQLLAB flag
Metabase row and column security -- sandboxed tables, plan requirement, and the documented SQL-editor bypass
Metabase permissions -- the permission model these controls sit inside
Streamlit documentation -- the Python data-application framework, included here as an adjacent category rather than a BI tool
Web Content Accessibility Guidelines (WCAG) 2.2 -- the W3C Recommendation of 12 December 2024, its four principles, and conformance levels A/AA/AAA