Multi-tenant reporting means one reporting environment serves many separate tenants, such as customers, business units or franchises, and each tenant sees only its own data. You get there with three layers: isolate the data (row-level filters, separate schemas or separate databases), control access (workspaces and permissions), and automate delivery so every recipient gets a correctly filtered, correctly formatted report on schedule. This guide walks through each layer, with the testing and delivery details that most explanations skip.
TL;DR
- A tenant is any group that must be kept apart: an external customer, a reseller, a franchise unit or an internal department.
- Enforce separation as close to the data as you can. Row-level security in the database or semantic model beats filters bolted on in application code.
- Delivery is where leaks happen. A scheduled export is only as safe as the filter applied when it runs, so test every tenant's output, not just the dashboard.
- Data-driven schedules (bursting) let one report definition produce a personalized file for each tenant without hundreds of hand-built subscriptions.
- Audit regularly: query as different users, compare results, and log every delivery.
Table of Contents
- What multi-tenant reporting actually means
- Three ways to separate tenant data
- Where row-level security meets delivery
- Scheduling and delivering reports to many tenants
- Testing and auditing for cross-tenant exposure
- Planning for scale and platform limits
- Our perspective
- Automate tenant report delivery with ChristianSteven
- FAQ
- Sources
What multi-tenant reporting actually means
In business intelligence, "multi-tenant" describes one platform serving several independent groups that share the same infrastructure while their data stays logically isolated. The tenants can be external, such as customers who receive a usage report from a SaaS product, or internal, such as regional divisions that must not see each other's payroll or margins. Partners, resellers and franchise units fit the same pattern.
The idea is simple. The execution is not, because the same report definition has to produce a different, safe result for every tenant. Every technical decision follows from one rule: Customer A must never see Customer B's data.
The opposite approach is a copy of the report, and often of the data, for every tenant. That works for five tenants and breaks at fifty. Multi-tenant reporting exists to avoid that maintenance load: one set of definitions, many isolated outputs.
Three ways to separate tenant data
Most designs fall into one of three database patterns, each trading isolation strength against scalability and operating cost, as Holistics' overview of multi-tenant analytics describes them.
| Pattern | How it works | Isolation | Cost and effort |
|---|---|---|---|
| Row-level filtering on shared tables | Every row carries a tenant ID; policies filter by it | Logical, depends on policy correctness | Lowest. One schema to maintain |
| Schema per tenant | Same tables, one schema for each tenant | Stronger boundary, easier per-tenant backup | Medium. Migrations run once per schema |
| Database per tenant | Each tenant has its own database | Strongest | Highest. Many databases to patch and monitor |
Choose by the cost of a mistake. Internal departments sharing one warehouse usually do well with row-level filtering. Regulated customers who contractually require physical separation point toward schema or database per tenant.
Row-level security: let the database do the filtering
Row-level security (RLS) restricts which rows a given user's queries can return. PostgreSQL describes it as a table-level feature that limits rows on a per-user basis. Snowflake's row access policies work at query time: the policy expression is evaluated when the query runs, and only rows for which it evaluates to true appear in the results.
Databricks makes the case for putting this at the database level rather than in custom application logic. In its view, RLS is secure by default, consistent across client tools and lower in latency, because filtering happens at execution time. That matters for reporting: your dashboard, your Excel export and your scheduled PDF all go through the same rule, so there is no "forgotten" path.
If you do filter in application code, never build the tenant condition by concatenating strings. The Apache Pinot documentation recommends using a SQL parser to inject tenant filters and then validating that the rewritten query still contains the filter, because string concatenation invites SQL injection.
Workspaces and permissions: control who opens what
Data filters answer "which rows." Workspaces answer "which reports." A common layout keeps a parent workspace for shared definitions and child workspaces where each tenant's users consume analytics, as GoodData's multi-tenant workspace documentation outlines. The same logic applies in the BI tools many of our readers run: Power BI workspaces and apps, Tableau projects and sites, SSRS folders and roles.
Keep the roles simple. A short list of roles mapped to tenants is auditable. A tangle of per-user exceptions is not.
Where row-level security meets delivery
This is the part the keyword "row level security delivery" points to. Interactive access is easy to reason about: a user signs in, the platform knows who they are, the filter applies. Scheduled delivery is different. A job runs unattended, often under a service account, and produces a file that then travels by email, a file share or a collaboration tool. Once the file leaves the platform, the platform's security no longer protects it.
So each delivered report must be generated with the right tenant context from the start. Three questions decide whether that is true:
- Whose identity does the job run as? If a scheduled export runs as an administrator with no RLS applied, every tenant's file may contain every tenant's rows. Confirm how your platform applies row-level rules to exports and subscriptions before you automate anything.
- Where is the tenant filter applied? Either at the data layer (the report queries as, or on behalf of, a tenant-scoped identity) or as a parameter passed to the report at run time. Parameters are fine when the recipient cannot change them and the value comes from a trusted list, not from user input.
- Who can receive the file? Recipient lists should come from a governed table that maps each tenant to its approved addresses or destinations. A typo in a hand-edited list is a data breach.
Scheduling and delivering reports to many tenants
Native scheduling in most BI platforms works well for a handful of reports. It strains when you have hundreds of tenants, each with its own filter, format and delivery time. Typical pain points are one subscription to create and maintain per tenant, limited export formats, limited destinations and little visibility when a run fails.
A reliable multi-tenant delivery process has these building blocks:
- A single report definition. One template per report type, not one per tenant.
- A recipient table. Tenant ID, recipient, filter values, format, language and delivery schedule in one governed place (a SQL table or a spreadsheet your team already controls).
- Data-driven bursting. The scheduler reads that table at run time and produces one personalized output per row. Adding a tenant becomes a data change, not a project.
- Format and destination per tenant. Some tenants want a PDF by email, others an Excel file on a secure share or in a cloud folder.
- Event triggers. Send when the data refreshes or a file lands, not at a guessed time that may precede the load.
- Error handling and retries. A failed run for Tenant 47 should alert someone and retry, not silently skip.
- A delivery log. Who received what, when, with which parameters. This is your audit evidence.
The same ideas apply whether you are bursting a Power BI report to franchise owners, an SSRS invoice summary to customers, or a Crystal Reports statement to suppliers. If your team is also looking at how dashboards fit in, our notes on what makes a great business intelligence dashboard cover the design side.
A worked example
Imagine a property management software company with 120 customers, each of which gets a monthly occupancy report and a weekly arrears summary. The company keeps one Power BI report for each type, a tenant_recipients table with 120 rows, and RLS on the semantic model keyed to the customer ID.
Each Monday at 6:00 a.m., after the overnight data load completes, the scheduler reads the table, runs the arrears report once per customer with that customer's ID, exports a PDF, and emails it to the listed contacts. Customers who asked for Excel get Excel. If a run fails, the operations team gets an alert and the delivery log shows which customers are missing.
Adding customer 121 means inserting one row. Nobody builds a subscription.
For teams that want help wiring this kind of flow into dashboards, AI automation support for dashboards is one more place to look at how tenant-specific reports can be delivered through shared or separate analytics workspaces.
Testing and auditing for cross-tenant exposure
Assume your first design has a leak and go looking for it. Three habits catch most problems.
Query as different users. Databricks suggests testing by querying the same protected table as different users and confirming that each sees only the permitted rows. Do this at the data layer, then again through the report.
Open the shared report as different tenants. Omniscope's guidance for multitenant reports is simply to open the shared report with different users and check what each one sees. Do it for a tenant with a lot of data and for one with almost none, because empty results expose filter bugs.
Test the delivered file, not only the screen. Generate the scheduled output for two tenants and compare totals against a known query. Open the Excel export and check hidden sheets, cached data and file properties, since an export can carry more than the visible page.
Then make it routine:
- Re-run the tenant tests after every report change, model change and permission change.
- Keep a canary tenant with known, unusual values (for example, a distinctive total) and alert if those values ever appear in another tenant's output.
- Review the delivery log monthly for unexpected recipients or destinations.
- Remove access promptly when a tenant leaves, and remove its row from the recipient table the same day.
Planning for scale and platform limits
Two things grow with tenant count: the number of runs and the cost of getting one wrong. Plan for both.
- Stagger the load. Running 500 exports at 6:00 a.m. hammers the data source. Spread them across a window or trigger them in batches.
- Know your platform's export behavior. Each BI tool treats parameters, RLS and file formats differently in exports. Test with your actual version.
- Separate the heavy tenants. One tenant with ten times the data can slow everyone. Isolate or schedule it separately.
- Keep definitions in version control or a change log. Shared definitions are powerful and dangerous: one edit reaches every tenant.
- Decide where files may land. Email is convenient but uncontrolled. For sensitive tenants, prefer a secured share or portal and send a notification only.
Our perspective
Most teams we talk with start multi-tenant reporting as a data problem and discover it is a delivery problem. The model is secured, the dashboards behave, and then the monthly PDFs go out through a patchwork of manual exports and hand-maintained subscriptions. That is where mistakes and late reports creep in.
We built PBRS, ATRS and CRD to close that gap. They are designed to schedule, personalize, export, package and deliver Power BI, SSRS, Tableau and Crystal Reports content to licensed or external recipients, with data-driven bursting, event triggers, multiple formats and multiple destinations. One report definition, one recipient list, many correct outputs.
Our software runs on premises, so you decide where credentials, data and generated files live. We hold SOC 2 Type II certification, and we have spent more than two decades making reporting workflows hands-free. Our advice: keep your row-level rules in the data layer, keep your recipient mapping in a governed table, and let a purpose-built scheduler do the repetitive work, with error handling and a delivery log you can show an auditor.
Christian Ofori-Boateng
Automate tenant report delivery with ChristianSteven
If you are spending hours each week exporting dashboards by hand, or you have outgrown the native scheduler in your BI platform, our tools are built for exactly this job. PBRS covers Power BI and SSRS, ATRS covers Tableau, CRD covers Crystal Reports, and IntelliFront BI centralizes dashboards, KPIs and reports. Both subscription and perpetual licenses are available, and you can start with a free trial or demo.
See how PBRS schedules and exports Power BI reports, or explore the full product line and pick the tool that matches your BI platform. Tableau teams can start with the ATRS Tableau scheduler, and Crystal Reports teams with the Crystal Reports scheduler.
FAQ
What is the difference between multi-tenant and single-tenant reporting?
In single-tenant reporting, each customer or group gets its own dedicated environment. In multi-tenant reporting, many tenants share one environment and the platform keeps their data logically separate. Multi-tenant is cheaper to run and maintain. Single-tenant gives the strongest physical separation.
Is row-level security enough to protect tenant data?
It is the foundation, but not the whole answer. You also need workspace permissions, a governed recipient list and tests of the delivered files. Verify by querying as different users and comparing results, as the Databricks guidance above describes.
Can one report serve hundreds of tenants?
Yes. Keep one report definition and drive the differences from a recipient table that holds each tenant's filter values, format and schedule. A scheduler with data-driven bursting generates one output per row, so adding a tenant is a data change.
How do I stop a scheduled report from reaching the wrong tenant?
Source recipients from a governed table instead of typed lists, apply the tenant filter at the data layer or through a locked parameter, and keep a delivery log. Add a canary tenant with distinctive values and alert if they appear anywhere else.
Sources
- Multi-Tenant Analytics, Holistics
- PostgreSQL documentation: Row Security Policies
- Understanding row access policies, Snowflake Documentation
- How to build data apps with row-level security, Databricks
- Multi-Tenant Analytics, Apache Pinot Docs
- Set Up Multiple Tenants, GoodData Cloud
- Omniscope multitenant report customisation