What a Business Intelligence Platform Does, and Which Kind You Need

What Is a Business Intelligence Platform? The Layers, Not the Product

A business intelligence (BI) platform is the software that connects to an organisation's data, models it into consistent, governed metrics, and delivers it as dashboards, reports and exploration to the people who make decisions, under access rules. It's best understood as a set of layers rather than a single product: data connection, a modelling or semantic layer that keeps definitions consistent, visualisation, governance and access control, and distribution.

Platforms differ in where those layers run and who they serve, from internal teams analysing their own business to customers viewing analytics inside a software product. Capabilities such as real-time refresh, cloud hosting or self-service describe how particular layers are implemented, not what the category is.

Most "best BI tools" lists rank products without ever saying what the category is. We think that's backwards, because you can't compare platforms sensibly until you know what a platform is meant to do.

So what does a BI platform include? Start at the bottom. The connection layer reads from your data sources, usually a data warehouse, and without it nothing above has anything to work with. In practice this is a data integration job across multiple data sources: the warehouse, a CRM, billing, product event logs and the occasional spreadsheet. The scale is the reason the category exists.

Data now sits in more systems than most companies have connected: MuleSoft's 2025 Connectivity Benchmark Report, a survey of more than 1,050 IT leaders, found the average enterprise running 897 applications, with only 29% of them integrated. Modern BI platforms respond with hundreds of native connectors and APIs, yet connection isn't the same as use: in Salesforce's 2025 survey of data and analytics leaders, respondents estimated that 19% of their company's data is siloed, inaccessible or otherwise unusable, and that 26% is untrustworthy. Connecting to raw data is only the first step.

Next comes modelling, the role often played by a semantic layer, where "revenue" or "active customer" gets defined once. Skip it and a common failure mode follows: two dashboards built by two teams show two different revenue numbers, and the meeting becomes an argument about whose structured query language (SQL) is right. Tools like dbt's Semantic Layer exist precisely to centralise those definitions. Modelling is also where data quality is won or lost: deduplicating records, handling nulls and agreeing which timestamp counts turn raw data into business data people can trust.

Visualisation turns governed metrics into charts people can actually read; done badly, accurate numbers still get misread. Modern BI platforms enable interactive visualisations and dashboards, so a user can filter, drill down and compare periods rather than stare at a static export. That's where data visualisation earns its keep: it helps people identify trends and patterns in historical data that would stay hidden in a table. A good platform should let you create custom, dynamic dashboards that refresh as the underlying data changes, so the view reflects the business as it is, not as it was at the last export.

Governance and access control decide who sees which rows and metrics, and it only works when it's enforced below the presentation layer (at the data, semantic, query or governed runtime layer), because hiding a chart isn't the same as restricting the data behind it. Distribution gets results to people: dashboards, scheduled reports, exports, or views inside another application. It's the layer that turns data analysis into actionable insights, because a finding nobody sees changes nothing.

That's the conclusion to carry forward. A business intelligence platform is defined by the layers it provides, not by any product's name.

Two tools with very different branding can be the same kind of platform, and two with similar names can serve entirely different audiences.

Why No Single Capability Defines a BI Platform

No single capability defines a BI platform, because features like real-time refresh, cloud hosting, self-service and AI each describe one layer or one deployment choice, not the whole stack. Most vendor pages lead with one feature and let it stand in for the whole category. We think that's where a lot of evaluations go wrong.

Three features show up constantly. Real-time describes how fresh the data is. That's a property of the connection and query layers: whether the platform queries a warehouse such as Snowflake live or reads from a cache refreshed on a schedule. Cloud describes where the layers run, not what they do.

Cloud-based BI platforms let people reach dashboards from anywhere with an internet connection, which is genuinely useful, but it says nothing about whether the metrics behind those dashboards are right. Self-service describes who gets to explore and how far, and it only holds up when the governance layer sets the limits.

The newest headline feature follows the same pattern. Modern business intelligence platforms now incorporate AI and natural language processing, so a user can type a question in plain English, and many add predictive analytics that forecast from historical data. These are real gains for data analytics, but an assistant answering "what was revenue last quarter?" is only as trustworthy as the metric definition underneath it. That's one reason data quality management ranks first among the trends in BARC's Data, BI and Analytics Trend Monitor 2026, a survey of 1,579 professionals.

What this isn't: a case against live data, cloud hosting, self-service or AI. They're often exactly what you need. The trouble starts when the advertised capability becomes the yardstick. A platform with live dashboards and a weak modelling layer will still hand two teams two different numbers for the same metric, just faster.

None of these features is the definition. Each is a choice about how a platform is deployed or how it implements one or two layers. Treat any one of them as the definition and you'll judge the platform on the wrong thing. Judge a platform across every layer, not by the capability it advertises most.

Types of Business Intelligence Platforms: Four Common Types and the Situation Each Fits

There are four common types of business intelligence platform. Each is the same set of layers (connection, modelling, visualisation, governance and delivery) arranged differently: the layers run in different places and serve different people.

The types make more sense with a little history. The term "business intelligence" was first used in 1865, by Richard Millar Devens in his Cyclopaedia of Commercial and Business Anecdotes, to describe a banker acting on information ahead of competitors. The software came a century later. In the 1960s, early BI and decision-support systems required significant IT involvement, and every new report meant a request to a technical team.

The 1990s brought data warehousing and online analytical processing (OLAP) into wide use, the foundation of enterprise BI. Self-service features emerged in BI platforms during the 2000s, cloud and warehouse-native tools followed, and today's platforms add AI, natural language querying and embedding inside other software. Each era left behind a type of platform that still fits a particular situation.

That's why we don't put much weight on category labels alone. Two products can both call themselves "modern BI" while one runs beside your data warehouse for your analysts and the other renders inside your product for your customers. They share the same layers but do a very different job. The three fields below are the ones we'd use to tell them apart.

• Traditional or enterprise BI. Who it serves: analysts, finance, operations and executives inside one organisation. Where it runs: usually a central server or managed service, often with its own data extracts and a centrally owned model. Where it fits best: standardised reporting across departments, with a central data team owning definitions and distribution.
• Cloud or warehouse-native analytics. Who it serves: data teams and analysts already working in a cloud data warehouse. Where it runs: it queries the warehouse directly instead of copying data out, so modelling sits close to the data. Where it fits best: organisations that have consolidated their data and don't want a second copy to reconcile.
• Self-service BI. Who it serves: business users who want answers without filing a ticket. Where it runs: on top of a governed model the data team maintains, a role often played by a semantic layer. Where it fits best: teams with heavy ad hoc analysis, provided metric definitions stay consistent underneath.
• Embedded (customer-facing) analytics. Who it serves: your customers' users, inside your software. Where it runs: within your product's interface, with each request scoped to the signed-in customer, commonly by passing identity as a signed JSON Web Token (JWT), defined in RFC 7519. Where it fits best: software-as-a-service (SaaS) products where analytics is part of what customers pay for. Our guide to embedded business intelligence goes deeper.

Read across the list and the pattern is plain: the types differ mainly in where the layers run and who they serve. Only one of them, embedded analytics, is designed first for people outside your company.

The First Question: Internal BI vs Customer-Facing Analytics

For a software company, the first decision about a business intelligence platform is who the analytics is for: your own staff, or your customers inside your product. The two audiences ask very different things of the same layers.

The questions differ too. Internal BI is where your own people do data analysis on business data: finance reconciling revenue, product teams studying customer behaviour, leadership tracking targets. Customer-facing analytics answers your customers' questions about their own activity, inside the workflow where they already are.

If the audience is your own team, an internal BI tool is the right choice, and the one you already run is probably doing its job well. Vendors draw this line themselves. Power BI is a mature internal BI platform, and Microsoft documents embedding for your organisation and embedding for your customers as separate scenarios with different identity and licensing requirements (Microsoft Learn). Teams have come to us after weeks spent comparing feature lists, only to find the real disagreement was about who'd be looking at the dashboards. That question was never on the spreadsheet.

So answer the audience question before you compare any tool. It's the first filter on which platforms are even candidates.

For the full side-by-side of the two categories, see our guide to embedded analytics vs business intelligence.

What Changes When Your Customers Are the Audience: Tenancy, Permissions and Look-And-Feel

When customers become the audience, tenancy, scoped permissions and native look-and-feel stop being nice-to-haves and become requirements. A common failure mode shows why. A customer's operations lead opens the usage chart in your product, sees a spike and asks support why. The chart was summing rows from three other tenants, because the filter that should have scoped it lived in the dashboard instead of the query.

That isn't a charting problem. It's a tenancy problem.

Once customers are the audience, three requirements become mandatory:

• Tenancy (multi-tenancy): Each customer's data is kept separate, whether by schema, by database or by a tenant key on every row.
• Permissions: Access rules are scoped to customer users, not your staff directory. They're enforced below the presentation layer, at the data, semantic, query or governed runtime layer. Row-level security (RLS) is the usual mechanism, and it holds when it's correctly applied to the relevant tables or views.
• Look-and-feel: The analytics reads as part of your product, with your fonts, components and navigation. It shouldn't look like a framed window into someone else's tool.

Internal BI needs enforcement too, because a finance analyst shouldn't see HR salaries. But the shape is different. Staff sit inside one organisation, sign in through your single sign-on (SSO) and will put up with a tool that looks like a tool. Customers do none of that. We think they're right to notice the seams, because the seams are your product.

These are requirements you have to meet, so an internal BI tool is a candidate only if it can meet them. Some can. Power BI has a well-documented "Embed for your customers" scenario built for this case. According to Microsoft Learn, production use requires a capacity-based licence. It also requires a Pro or Premium Per User (PPU) licence when the embedding identity is a master user account rather than a service principal. That path works for many teams, but it's a licensing and architecture decision to make on purpose before you commit, not one you discover after launch.

When an Internal BI Tool Can Serve Customers, and When It Can't

An internal BI tool can serve customers when the need is light and the licensing covers external viewers; it strains once tenancy, permissions and branding become core to the product. Sometimes the tool you already own is the right answer. We'd say so plainly.

If your customers need a handful of fixed reports, your tenant count is small and branding isn't a selling point, embedding your internal BI tool is often the quickest honest route. The condition is licensing. In that scenario, the content has to sit in a Premium, Embedded or Fabric capacity workspace, because Pro or Premium Per User licences alone don't cover external viewers (Microsoft Learn). Get that right, and a light customer-facing need can live on the platform your data team already runs.

Where it strains is depth. These tools were built for internal reporting first. Microsoft does sell a customer-facing route, pitching Power BI Embedded as a way to "white label Power BI" for customer-facing dashboards, with viewers who "do not need Power BI licenses assigned to them" (Azure pricing). But each customer requirement still tends to become something you configure around rather than something the model expects.

If you isolate each customer with its own workspace or a fixed role, that turns into sprawl you have to keep in step with your product's own accounts. One shared model with row-level security avoids most of it, but then every embed token has to carry the right customer's identity.

Permissions have to be enforced below the presentation layer (at the data, semantic, query or governed runtime layer) for every customer user, not just every analyst. Theming usually stops short of making charts feel like your app. None of that is impossible; it just gets heavier with each customer you add.

That's the point where we think a platform built for customers fits better. Full disclosure, this is our product: Embeddable helps software teams build customer-facing analytics in code — without owning the infrastructure burden underneath. It isn't a replacement for internal BI, and we wouldn't pitch it as one.

The trade-off is real. You'll run two tools: one for your staff, one inside your product.

So here's our verdict. Light needs can fit an internal tool if it's licensed for external users. Once tenancy, permissions and native look-and-feel are core, a platform designed for customers is the better fit.

How to Choose a Business Intelligence Platform: Questions to Take Into a Vendor Evaluation

To choose a business intelligence platform, settle who the analytics is for, then test every layer against your own data and write the answers down before the first demo. Without written criteria, the ranking drifts toward whichever feature the vendor demoed best.

1. Who is this for? Staff or customers decides which platforms are candidates at all.
2. Does it connect to where our data lives? Check connectors to your data warehouse and other data sources, whether queries run there or on copied data, and how much data integration work it takes to combine multiple data sources.
3. Where are metrics defined? You want a governed layer, often a semantic layer, so "active user" means one thing everywhere, and a clear way to flag data quality problems before they reach a dashboard.
4. Can it show what our users need? Test real charts and ad hoc analysis on your own data, including historical data at realistic volume, not a sample set.
5. Where are permissions enforced? Ask whether access rules hold below the presentation layer (at the data, semantic, query or governed runtime layer), and how it integrates with single sign-on (SSO) via OpenID Connect or SAML.
6. How does it deliver results? Confirm the dashboards, exports and scheduled reports your users expect, and whether AI or predictive analytics features run on the same governed metrics as everything else.
7. For customers: how is each tenant isolated, and will it look like our product? Ask to see multi-tenancy working on your schema, plus styling that matches your design system.
8. For customers: does cost move with the value of the viewers? One fixed price per viewer can't suit both a million students and twelve fund managers, so ask whether you can model the cost before a sales call.

The order matters. Question one filters the field, questions two to six apply to any of the BI platforms on your list, and seven and eight only apply once customers are the audience. We think answering them in sequence is the single best defence against a vendor-shaped shortlist. Go into every evaluation with the audience question settled and your criteria in writing, so the ranking reflects your needs instead of the vendor's. If customers are the audience, our embedded analytics requirements checklist goes deeper.

Related Reading

• Power BI Embedded Analytics
• Power BI Row Level Security
• Embedded Dashboards
• Semantic Layer for AI Agents
• Dashboard Builder Customer Facing Analytics