In the last couple of years prior to the Corona pandemic, I was lucky enough to do presentations and sessions with Daniel Laskewitz, a Microsoft MVP for the Power Platform. We focussed on the topic of citizen development as related to compliance and governance.
Or, in other words, how can we keep our business/citizen developers happy and support them in creating powerful apps and workflows, while also adhering to internal and external rules and regulations? Most of the time we were able to come up with easy-to-use solutions. For example: using environments and Data Loss Prevention rules. But there always was one scenario that offered some challenges: cross-tenant connections.
What’s this all about? The PowerPlatform uses connections in able to work. When you create a Flow (sorry: Power Automate Flow), you will need to add the connections required for your Flow to work. These connections use identities that need access to the resources you are connecting to.
So far, so good. This makes sense. Now you can add DLP rules to allow for separating or even blocking specific connectors. If you don’t want to have your Dynamics information automatically converted to a Twitter Tweet, then don’t allow these connectors to work together. But here’s the snag. What if I use multiple identities in my connections?
An example; I’m a user and have access to multiple Microsoft 365 tenants. I use different identities to log in to these tenants. And I want to have all documents stored in a SharePoint Online site in the Contoso tenant to be copied to my Fabricam tenant when these are created. At this moment, this is no problem. There’s no DLP policy to block this action.

And as Daniel and myself used to note: “call Microsoft for this”. Just (kinda) kidding of course. You could request Microsoft to enable tenant isolation to solve these issues. But this year, Microsoft released the tenant isolation feature in preview.
Please note the preview bit. Microsoft is still working on the feature, so it might not work as you might expect. But here’s a small rundown. Tenant isolation uses tenant rules to be set either for inbound, outbound traffic, or both. WHen these are set, you can enable the isolation mode by flicking a switch 🙂


To set up the isolation tenant rule, you will need to either enter the domain or the id of the tenant in question. You can also use the wildcard * to select all tenants.

After enabling the mode and/or making changes to the policy, it might take up to one hour to take effect. After which, you developers will see an error message when they try to connect to resources in the other tenants. By the way: this still needs some work, in my opinion. Either inform the developer that this is because of an administrative setting within the error message or inform them prior to enabling the isolation mode. Both would probably be ideal.


Like I said, this is still in preview. If you want to learn more on this feature, then go to: https://docs.microsoft.com/en-us/power-platform/admin/cross-tenant-restrictions?WT.mc_id=EM-MVP-5003084Â
How would you assess what the impact of enabling this would be?
Hi Jon,
When operational, the isolation mode should disallow Power Apps and Power Automate Flows to be created in one tenant and connecting to resources in another tenant. By default. You can add domains that need to be able to read/write to your tenant. It probably does not solve the problem when using a commercial (“free”) version of the platform to connect to an enterprise (tenant) environment. But to be honest: I need to do a deep-dive test on this.