Almanac
Microsoft/dataversePower Platform

Consultant KB for Microsoft Dataverse, the data layer under Dynamics 365 and the Power Platform: data model, security model, business logic, APIs and integration, search and queries, analytics and Fabric, ALM and solutions, administration, governance and compliance, and Dataverse as an agent data platform, 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 Dataverse release plans, docs repo and product blog, plus the author's own consultant notes.

feature-tenant-isolation.mdv1 · history
CurrentApplies to AdminUpdated last monthSource Microsoft Learn

What it does

Tenant isolation controls whether Power Platform connections can be established across an Entra tenant boundary — outbound from your tenant to someone else's data, or inbound from another tenant to yours. It applies to connectors that authenticate with Entra ID, such as Microsoft 365 Outlook and SharePoint.

Key facts

  • Default is Off, which means any user presenting valid Entra credentials can establish a cross-tenant connection in either direction. That's the posture most tenants are in without knowing it.
  • Turn it On and all tenants are blocked in both directions until you add exceptions. There's no "block outbound only" master switch — direction comes from the rules.
  • Exception rules are per direction: inbound, outbound, or entries for both. * as the tenant ID allows all tenants in that direction.
  • Rules accept either a tenant domain or a tenant ID; the admin centre resolves a domain to an ID for you.
  • The rule threshold is 500 entries, described as a technical limitation.
  • Rules can be added and edited while isolation is off, but they aren't enforced until you turn it on.
  • Configured under Security > Identity and access > Tenant isolation in the Power Platform admin centre. You need the Power Platform administrator role even to see the page.
  • This is not Entra ID-wide tenant restriction. It doesn't affect Entra-based access outside Power Platform, and it doesn't cover connectors that don't use Entra authentication.
  • A guest user connecting from their own 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 existing apps and flows — not instant.
  • Design-time effect: makers get an error and can't add the connection. Power Automate saves the flow but marks it Suspended until the violation is resolved. Runtime effect: existing flows fail with an error in the run history.
  • Known gap: the Azure DevOps connector uses Entra as identity provider but issues tokens through its own OAuth flow, so tenant isolation isn't enforced for it. Microsoft's recommendation is to restrict that connector through data policies instead.

When to use / skip

Any organisation that treats data exfiltration as a real risk should have this on. The typical enterprise posture is isolation on, two-way, with a small explicit allow list covering genuine partner tenants, joint ventures and the client's own secondary tenants after an acquisition. Getting there is the work, not the switch — you turn it on and discover which cross-tenant connections were quietly load-bearing. Run the cross-tenant isolation reports first, build the allow list from what they show, then enable. Skipping the reporting step is how you take down a supplier integration on a Tuesday morning.

Configuration decisions

  • Two-way isolation versus allowing one direction, which is really a question about whether the concern is data leaving or data arriving.
  • The allow list itself: which partner tenants, in which direction, and who approves an addition.
  • Whether the rollout is staged — rules first while off, then on — and what the rollback trigger is.
  • What happens to connectors outside the Entra authentication model, since those need data policies rather than isolation.
  • How the allow list is reviewed, given it's a standing list of organisations your data can move to.

Gotchas

  • Turning it on blocks everything in both directions immediately. There's no report-only mode, so the reports have to be run beforehand.
  • The Azure DevOps connector isn't enforced. If insider exfiltration through ADO is in your threat model, tenant isolation doesn't close it — a data policy does.
  • The hour-long assessment delay means a change looks like it did nothing, then breaks things later. Don't let anyone test by refreshing.
  • Suspended flows aren't obviously suspended to the maker who saved them. The flow saves successfully and simply never runs.
  • Allow list entries have no effect while isolation is off, so a tenant that toggles isolation off "temporarily" has all cross-tenant traffic open again regardless of the rules.

Consultant notes

  • Frame the allow list as a supplier register rather than a technical setting. It's a list of organisations your users are permitted to move data to, and the business should own it.
  • Warn about guest-user scenarios early. Consultancies and partners working in the client's tenant often hit this, and the exemption for host-tenant-to-host-tenant connections is narrower than people assume.
  • Pair tenant isolation with data policies in the same governance workshop. Neither is complete alone — isolation handles the Entra-authenticated connectors, policies handle everything else.
  • Get the 500-rule threshold on the record for any client with a large partner ecosystem. It's generous, but it's finite.

Worth revisiting if the Azure DevOps connector gap is closed, or if isolation gains a report-only mode.

Was this accurate?