When your SaaS company starts offering embedded reporting to customers, one question rises above all others: how do I guarantee customer A never sees customer B's numbers?
This is where many embedded analytics projects stall. If you search the web for "multi-tenant analytics security", "customer-facing reporting" or "multi-tenant dashboard", you'll find plenty of scaremongering and little substance. Let's fix that. We'll walk through how data isolation actually works — and why we build customer portals specifically on Microsoft Power BI.
Why one report is enough for a hundred customers
The temptation is to give every customer their own copy of the report with their own data. It feels safe — separate files, no risk of mix-ups. In practice it's a maintenance nightmare: a single change to one visual has to be repeated across dozens or hundreds of copies.
The scalable model is one report whose data filters automatically based on who is viewing it. This is what Row-Level Security (RLS) enables: you define a rule on the report that limits the visible rows based on who's looking. One report, one data model — but a different view for every customer.
Why we chose Power BI — RLS is genuinely grown-up there
We've built multi-tenant analytics on several tools, and Power BI's Row-Level Security is the reason it's our default choice for customer portals.
RLS isn't a bolted-on extra in Power BI — it's part of the data model. The filter rule lives in the same place as the data itself, tested by Microsoft and battle-hardened across thousands of companies. When the viewer's identity is passed to the report, filtering happens on the server, in the data layer — not in application code that every developer would have to reimplement and where every mistake is a potential leak.
In other words: we don't use Power BI despite data isolation being hard, but precisely because Power BI makes it reliable.
Three layers that keep customers' data apart
A secure multi-tenant portal doesn't rely on a single check, but on three overlapping layers. If one fails, the next stops the leak.
1. Access control in the portal — who is even allowed to see the report
Before any data is fetched, the portal verifies the logged-in user's session and which reports their organization is entitled to. This isn't left to the browser: even if a user guessed another report's identifier and tried to open it directly, the server checks the entitlement in the database — otherwise the answer is an unambiguous "no access".
2. Data filtering in the embed token — which rows the report shows
This is the layer that makes the multi-tenant model secure. When the portal requests a viewing permit (embed token) from Power BI, it attaches the viewer's identity and role. A customer-specific identifier goes along with it, and the RLS rule filters the data on the Power BI side — before a single row leaves the server for the browser.
The key point: the customer doesn't receive "all the data with some of it hidden", but physically only their own rows. Browser dev tools can't reach what was never sent.
3. Short-lived token — how long the permit is valid
The viewing permit isn't permanent. The embed token expires after about an hour by default, and we scope it to a single report at a time. Even if a token somehow leaked, its lifetime is minimal and it can't reach other reports or datasets.
The most common mistake: trusting what the browser tells you
Most data leaks in this model don't come from Power BI but from access control being built in the wrong place. If the application decides what to show on the browser side — for example, hiding the "wrong" customer's reports only in the UI — the data is still retrievable by anyone who knows how to inspect network traffic.
The rule is simple: every data request is verified on the server, every single time. The user's session, the organization's entitlement to that specific report, and the data filtering all happen server-side. The browser only ever receives a pre-filtered result.
What about when more customers come along?
The beauty of this model is that it scales with no extra work. A new customer means a new row in the entitlements table — not a new report, not code changes, not a fresh security review. The same tested filtering logic applies to customer number 2 and customer number 500.
Summary for a SaaS leader
A multi-tenant analytics portal is entirely safe to build when data isolation is done in the right layers:
- Access control decides who sees the report at all
- RLS in the embed token decides what data the report shows
- The short-lived token limits how long and for what the permit is valid
This is exactly why we build customer portals on Power BI: data isolation doesn't rest on application code, but on Microsoft's battle-hardened RLS model. That's how you can offer the same report to a hundred customers with confidence — each one sees only their own.