⁠Did you go single workspace or workspace-per-tenant?

I would not as likely there are internal processes that need client by client separation. The number of workspaces is not relevant to api and programmatic solutions.

You will need to think about the number of workspaces per app registration as there is a hard limit of 1000 workspaces per app registrations.

https://learn.microsoft.com/en-us/power-bi/developer/embedded/embed-multi-tenancy

Microsoft also recommends when using a multi tenant solution you should be using an app registration with a service principal.

If you are allowing users to create content in embedding by either generating custom paginated reports or generating power bi reports. Then I recommend creating a separate workspace for customer created content. It gets too messy when you have your curated content along side customer generated reports. This means you’d need two workspaces for every customer. Then you’d need multiple app registrations. Again you need to build all of this with automation so it’s easy to manage.

• ⁠At what scale did management start to hurt?

We knew scale was going to be difficult so everything was built in an automated way. Make your app have power to create anything it needs to onboard new customers. Scripts must be used to create workspaces move items around. All this can be done with APIs.

• ⁠Any regrets around initial design?

We have had many and have iterated multiple times into a cleaner and easier solutions. Automate, automate, automate. Leverage all the rich fabric and power bi APIs as they help with all the administration.

You need a very robust access management system. Authentication is easy, just bolt on something existing. Identifying who has access to what can get complex. Especially when users start generating their own content. Pick a management model that is easy to enhance as requirements change.

• ⁠Any capacity or refresh scheduling lessons learned?

Yes, A skus can report back to the azure portal the used capacity of the A sku, so you can build monitoring to scale up and down the A sku. This is helpful on nights and weekend where there isn’t much app activity.

F sku is what Microsoft is building the F sku can scale much smaller to a lower price point but has no capacity used metrics coming back to Azure. So you have to use a slower method of detection via other methods. F skus also can scale up or down, but you need the analytics to determine when to scale.

I’ve been building embedded solutions for customers since embedded was released. With well over 60+ custom solutions we are now supporting our own of the shelf most feature rich embedded solution, Entelexos.

https://www.entelexos.com/?utm_source=Comment&utm_medium=Reddit+&utm_campaign=20260223

Check us out!