Is Creating a Separate Tenant for Embedded Reports in Fabric a Good Practice?

[Jsola]

Hi,

We are building a reporting system based on Microsoft Fabric, where reports will be embedded in our application and accessed by our customers.

We are considering creating a new tenant to manage around 500 workspaces (one per customer) and configure Fabric admin settings, Azure service principals, and other necessary components specifically for these embedded reports.

Currently, we have an existing tenant with many corporate reports and users. For security and administrative reasons, we believe that setting up a separate tenant might be the best approach.

Our question is:
Is it a good practice to create a separate tenant for this case, or should a separate tenant only be considered for special scenarios?

We would appreciate any insights or recommendations.

Many thanks in advance!!!

[ibarrau · Accepted solution]

Hi. I don't think there is a good practice talking about that. I would say the best here is kind off the one that fits better for your company and maintainance. I would probably say no to prevent data silos or duplications. If you already have some reports in one tenant, keep it that way. If you want to separate what is for embedded and what's not, then you could use a naming convention for the workspaces, you can use fabric domains or even keep different capacities. That way it's separated to maintain and still in the same place.

I hope that helps,

[Jsola]

Hi. You are right. On paper, anything is possible. But in the real world, we have to deploy systems that make life easier, and it's difficult to see the right path.

Thanks a lot for your support.

[Jsola]

Hi,

Thanks for your quick response.

We want to separate because Fabric admin options will be different, we want to know client consumption by client, avoid incorrect security management.  Current tenant is a bit chaos 😁

I will change the question 😁: Are there any contraindications to deploying a new tenant?

Thanks again

Josep Solà

[ibarrau · Accepted solution]

That's why I said that there is no good practice haha. In real world, it depends. If you want to keep a clean differente environment, you can do it in a different tenant. Well, contraindications, you could have duplication or rework if there are reports that should be shared internally and also in the webapp. Also you won't be able to take adventage of the capacity features for internal use unless you have two capacities. In addition, the onpremise sources will require two on premise data gateways (I'm not sure if you can host two in the same machine)

Personally, if you will have fabric and capacity admin in the current tenant. You could work in a clean domain of workspaces at the dedicated capacity and just look that. You could work in a nice naming convention. With all that the logs and measures could be filtered to monitor in a nice clean way. But again, it depends on how the company works, internal flows, burocracy, mates, etc.

I hope that make sense.

[ibarrau · Accepted solution]

Hi. I don't think there is a good practice talking about that. I would say the best here is kind off the one that fits better for your company and maintainance. I would probably say no to prevent data silos or duplications. If you already have some reports in one tenant, keep it that way. If you want to separate what is for embedded and what's not, then you could use a naming convention for the workspaces, you can use fabric domains or even keep different capacities. That way it's separated to maintain and still in the same place.

I hope that helps,