Skip to main content
Showing results for 
Search instead for 
Did you mean: 

Register now to learn Fabric in free live sessions led by the best Microsoft experts. From Apr 16 to May 9, in English and Spanish.

New Member

Power BI Embedded multi-tenancy architectural patterns

We've got a multi-tenant SaaS application, deployed in Azure, and are looking into utilizing Power BI Embedded for serving Analytics.


Basically I'm trying to understand some architectural options specific to the multi-tenancy aspects but can't find any references to architectural patterns specific for multitenant apps utilising Power BI. 


For reference, each tenant will have a common database schema for the data, but we have followed the 'Database Per Tenant' pattern (


I was expecting to be able to define reports/dashboards/datasets etc at a level above workspaces so they could be referenced per workspace but this doesn't seem to be a design feature (unless I'm missing something)


As far as I can understand, we have 2 options for a multitenancy model. Any suggestions/experiences would be greatly appreciated.


NOTE: Apologies for any newbie gaffs as I'm just understanding the scope and feature set of Power BI so may be missing some fundamentals here!!


Option 1 - Workspace Per Tenant

Setup a singe 'Tenant Workspace Template' workspace that has all of the reports/dashboards we would make available


With this we could utilise the Powershell in the following article to duplicate a 'template' workspace (when a tenant is onboarded)


We then would have to fix up the datasources to point to the correct to the correct database for that particular tenant (this I have already POC'd using the PowerBI client sdk).


- clean seperation of workspace per tenant
- dedicated datasource to tenant data (good data isolation)


- maintenance nightmare (updates to reports in the central 'Tenant Workspace Template' would need to be propagated to 100's/1000's of tenant workspaces).

Option 2 - Single global workspace with dynamic datasource routing


I'm not sure if this can be done, but potentially for each request, dynamically lookup the correct datasource depending upon the claims of the user.


- Single report/dashboard/dataset definitions
- No maintenance across tenants (ie single sources/codebase)


- Must have bullet proof datasource routing (ie risk of serving incorrect tenant data)


Helper III
Helper III

Option #1 maybe isn't a maintenance nightmare, since the APIs to manage this are available. You may need to take care to schedule updates outside of hours or something.


Something that would be useful would be the ability to programmatically (and via edit tags against various Power BI objects (reports, dashboards, datasets, etc). Then your application could use this metadata to determine which reports to update, etc, etc.

Hey thanks for your response!


I agree with you that Option 1 is definately possible albeit it adds to the devops surface area.


For me it feels like multitenancy SaaS integration isn't their prime use case for PowerBI Embedded at the present time. Hopefully this may be something that comes in the future to reduce the development effort of integration.

Helpful resources

Microsoft Fabric Learn Together

Microsoft Fabric Learn Together

Covering the world! 9:00-10:30 AM Sydney, 4:00-5:30 PM CET (Paris/Berlin), 7:00-8:30 PM Mexico City


Power BI Monthly Update - April 2024

Check out the April 2024 Power BI update to learn about new features.

April Fabric Community Update

Fabric Community Update - April 2024

Find out what's new and trending in the Fabric Community.