Almanac
Microsoft/power-automatePower Platform

Consultant KB for Microsoft Power Automate end to end: cloud flows, desktop flows and RPA, connectors and integration, AI and agent flows, process and task mining, approvals and human-in-the-loop, ALM and solutions, governance and security, licensing and capacity, monitoring and troubleshooting, plus cross-cutting decision guides. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power Automate release plans, docs repo and product blog, plus the author's own consultant notes.

power-automate/08-governance-and-security/feature-tenant-isolation.md
feature-tenant-isolation.mdv1 · history
CurrentApplies to Cloud flowsUpdated last monthSource Microsoft Learn ↗

What it does

A tenant-level switch that blocks Power Platform connections crossing between your tenant and any other, in either direction, even when the user holds valid credentials for the other side. Exceptions are added as an allow list of specific tenants per direction.

Key facts

  • Off by default. With it off, a user with valid Entra credentials for another tenant can create a cross-tenant connection with nothing standing in the way.
  • Turn it on and all tenants are restricted, inbound and outbound, until you add exceptions.
  • Inbound means connections into your tenant's data sources from external tenants. Outbound means connections from your tenant out to theirs. They're allow-listed separately.
  • Allow list entries take a tenant ID or a tenant domain — the admin centre resolves the domain to an ID for you. * allows all tenants in that direction.
  • The documented threshold limit for rules is 500.
  • It only covers connectors that use Entra ID-based authentication, such as Office 365 Outlook and SharePoint. It's a Power Platform control, separate from Entra ID-wide tenant restrictions.
  • Configured under Security > Identity and access > Tenant isolation in the admin centre. You need the Power Platform administrator role.
  • A connection attempt by a guest user, from their home tenant to data sources in that same home tenant, isn't evaluated by the rules.
  • Policy changes take about an hour to be assessed against active apps and flows.
  • Design-time impact: the flow still saves, but it's marked Suspended and won't run until the maker resolves the violation. Runtime impact: existing flows fail, and the failure shows in run history.
  • Known issue: the Azure DevOps connector authenticates through its own OAuth flow and STS, so the token isn't from Entra ID and the isolation policy isn't enforced for it. Microsoft's recommended mitigation is data policies restricting that connector.

When to use / skip

Any client with an insider-risk or data-exfiltration concern should have this on, and most regulated ones already do. The interesting work is the allow list, not the switch. Skip the fight if the client is a genuinely federated group of businesses sharing data across tenants daily — you'll spend longer maintaining exceptions than you'll gain in assurance. For everyone else, on with a short allow list is the sensible enterprise posture.

Configuration decisions

  • One-way or two-way. Outbound-only isolation stops your data leaving; inbound-only stops others connecting in. Most enterprises end up with both.
  • Which partner, subsidiary or acquired-company tenants go on the allow list, and in which direction each.
  • Whether you build the allow list before flipping the switch, using the cross-tenant isolation reports to find what's actually in use.
  • Who owns allow list changes and what the approval path looks like, since each entry is a deliberate hole.
  • Whether the Azure DevOps gap needs a compensating data policy.

Gotchas

  • The allow list can be edited while isolation is off, but it isn't enforced until you turn it on. People configure exceptions, see nothing change, and assume it's broken.
  • Turning it on without running the reports first is how you break every flow the client has with an acquired business, all at once, about an hour later.
  • It doesn't touch Entra ID access outside Power Platform. Security teams who think they've turned on tenant restrictions across the board are wrong, and it's worth saying so plainly.
  • Connectors that don't use Entra ID authentication are simply out of scope. This is a control on one class of connector, not a general boundary.
  • The failure at runtime looks like an ordinary flow failure in run history. Without context, makers will spend a day debugging their own logic.

Consultant notes

  • Run the cross-tenant isolation reports as a discovery exercise even if the client isn't ready to turn isolation on. The list of tenants they're currently connected to is usually the most interesting slide in the governance workshop.
  • Sequence it: reports, then allow list, then enable, then monitor. Skipping straight to enable is a production incident with a change record attached.
  • Set expectations with the security team about scope. This is one control among several — pair it with data policies and conditional access rather than presenting it as the answer.
  • Tell the client about the Azure DevOps gap explicitly. It's documented, it's real, and it's better coming from you than from their pen tester.

Check whether the Azure DevOps enforcement gap has been closed before quoting this as complete coverage.

Was this accurate?
Related
Data loss prevention (DLP) policies08-governance-and-securityConnections, authentication and OAuth03-connectors-and-integrationService principals and application users08-governance-and-securityOn-premises data gateway03-connectors-and-integrationCommon failure patterns10-monitoring-and-troubleshootingManaged Environments08-governance-and-security