Power BI Embedded multi-tenancy architectural patterns

[Heath]

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 (https://docs.microsoft.com/en-us/azure/sql-database/saas-tenancy-app-design-patterns).

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)
https://powerbi.microsoft.com/en-us/blog/duplicate-workspaces-using-the-power-bi-rest-apis-a-step-by...

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).

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

Disadvantages
- 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.

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

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

[jimmcslim]

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 PowerBI.com) 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.

[Heath]

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.