Hi @migueldfr,
I've had a similar use case for a client project not too long ago, so I unfortunately know that the infos you can find on how to handle projects like that are pretty scarce...
One thing you need to consider before choosing a reporting approach is how you'll handle access management overall. How many individual users do you expect to access your platform? How will new users be added - can they sign up directly via an order process on a website, will you manually process their sign-ups and create their accounts, or will you sync their information from an existing CRM? Where do you store their personal data (in Fabric, an existing DB, Dataverse, some CRM-system)? And how will you handle access control and mapping if you have different reports that the users may or may not be allowed to see?
Since you mentioned that clients should see only their own data and that everything needs to be completely isolated, there's the question on how their data is fed into the system.
Another important factor is the skill set available in your project team. Do you have any Web Developers or Power Page Experts? What else do you need to "wrap" around the reports on your platform - for example data entry for the reports, file uploads, or perhaps even a shop system where the users can directly buy access to specific reports? Or is the platform purely to display reports?
The best solution changes depending on your answers.
Example:
Let's assume that:
- You don't have any in-house web/PowerPage Developers and a limited budget for the web-framework (so You can't just pay a web development team to build a full platform from scratch).
- You have a small number of end-users that need to access the reports (e.g. fewer than 100).
- You don't need a fancy website around the reports; users only care about viewing the reports themselves.
- User management is handled through an existing CRM (so only existing manually approved clients get access to the platform, and you already store role and expiry information in your CRM)
In that situation my suggestion would be to set up a separate client tenant dedicated only to report acces. You can use Azure Functions to either create new AD users or add existing client org accounts as guest users, and then assign the appropriate AD roles for RLS and access management within that tenant. The same Azure Functions can also handle assigning and removing Power Bi Pro licenses automatically for each new (or expiring) user, based on the information stored in your CRM. The functions could run at predefined intervals to create, update, or delete accounts as needed.
You could then use the Power BI REST API (also triggered through Azure Functions) to create/update/delete at least one separate workspace for each client organization, ensuring complete data isolation. Each client would only have access to their own workspace, where they would view the reports via an Workspace App (or Org App once they become GA for Pro Workspaces).
I would recommend this appoach (assuming the base criteria I mentioned earlier) since it allows for:
- True data isolation: No risk of RLS misconfigurations or accidental cross-client visibility
- Automated lifecycle management: Onboarding, license assignment and workspace provisioning would all be driven directly from your CRM data
- Predictable license costs: It's a lot easier to predict and scale the monthly licensing costs based on your user growth and you can still replace it later with an embedded capacity if needed as you scale up.
- Flexibility: You can easily adapt your architecture and solution toward and embedded or Fabric-based model later without needed any major rebuilds.
- No web development overhead: You don't need to build a whole website including secure user handling, MFA, SSO etc. (beyond the automated account creation/deletion via the Azure Functions), and you don't have the (IMO quite steep) costs of a Power Pages site. But you still have the option to embed your reports if you really want to.
It's a bit more tricky if you expect multiple hundreds of users right from the beginning. For that scenario I'd would need to take a closer look at your exact project scope to see which approach would work best for your specific case.
Did I answer your question? If so, please consider marking my response as the ‘Accepted Solution’ - it helps others with the same issue find the answer more easily!
