Generate a document from a Dataverse record and you are not looking at one system doing one job. The record lives in Dataverse. A cloud flow reads it. A connector calls out to populate a template. The finished file lands in SharePoint, or gets attached to an email and sent out. That is four systems at minimum, each with its own documentation, and Microsoft does not walk you through the full path in one place.
Ask a compliance team where that data physically sits at each step and you get confident answers for some of it and silence for the rest. Microsoft commits to a fair amount about where Dataverse data lives at rest. The connector layer, and the Word Online template engine specifically, is where the documented answer runs out.
What stays inside the tenant
Dataverse stores your data in the tenant's assigned Azure macro region geography, what Microsoft calls the home geo, unless the organisation has set up a multi-geo deployment. That commitment comes from Microsoft's Power Platform data storage documentation. A macro region geography is the data residency boundary that lines up with the data residency laws for a given geography, such as North America, Europe, or Asia-Pacific.
Admins pick the macro region rather than a specific datacentre, and the platform assigns the actual datacentre within that region based on capacity, availability, and performance. Organisations with Advanced Data Residency enabled across all their Microsoft 365 seats get a tighter version of this. They can select the specific datacentre region for Dynamics 365 and Power Platform, and their data at rest sits in that named region. The formal commitments about where data at rest lives sit in the Data Processing Terms of the Microsoft Online Services Terms. The admin documentation only summarises them.
A document generation flow that reads a Dataverse record, runs its logic inside Power Automate, and writes the output back to Dataverse without calling out to anything external puts no external connector in the path at all, which is the model behind how VerseDocs keeps generation inside the tenant. That removes the clearest route for data to leave. It does not settle the region question on its own, because Microsoft does not publish where Power Automate executes a flow geographically, and an absence of documentation is not a guarantee.
What happens when a flow calls a connector
The moment a flow needs something outside Dataverse, the picture changes. Power Apps and Power Automate talk to Dataverse directly, with no separate connector in between. External data sources work differently. Microsoft's connect-data-sources documentation describes an API Hub that sits in front of external connectors, handling authentication token exchange and credential storage, with traffic routed through Azure API Management as part of what Microsoft calls its connector infrastructure.
Microsoft's connector protection documentation is direct about who answers for that data once it moves. Responsibility for protecting it follows the service handling it. Data sitting on Microsoft infrastructure stays under Microsoft's control. Once it moves to external infrastructure, the verified publisher of that service takes over that responsibility instead of Microsoft. That is a statement about who owns risk once data leaves Microsoft's own systems. It says nothing about which datacentre the request passed through to get there.
Tenant isolation adds one more layer, and it is narrower than the name suggests. It only applies to connectors that use Microsoft Entra ID based authentication, such as Office 365 Outlook and SharePoint. The Azure DevOps connector is a documented exception where tenant isolation does not apply at all. Left at its default setting, tenant isolation is off, and cross-tenant connections succeed with valid Entra credentials. Turned on, all cross-tenant connections are blocked unless the remote tenant is added to an allow list. Either way, tenant isolation governs which tenants a connection can reach. None of that speaks to which region the connector infrastructure itself runs in.
What plug-ins do differently
Dataverse plug-ins get the most precise documentation of any layer in this chain, which makes them worth calling out on their own. Microsoft states directly that Dataverse always uses the default options of sandbox and database for plug-in assembly deployment. That sandbox is not a suggestion. It restricts a plug-in to calling IOrganizationService methods, Azure solution methods, or reaching a network through a web client, and Microsoft's own documentation says the sandbox enforces those restrictions rather than leaving them to convention.
Telemetry backs this up with a field you can actually check. The IsolationType value in Dataverse telemetry logs records whether a plug-in ran in the sandbox, marked as 2, in no isolation at all, marked as 1, or in an external mode, marked as 3. Organisation web service calls a plug-in makes are logged as dependencies, and Microsoft's telemetry documentation confirms that plug-in code execution happens within the plug-in code itself, inside that sandbox.
None of that describes a tenant or a region though. A plug-in can be written to post its data context to a service bus through the service endpoint notification service, and that does move data outside Dataverse by design, if that is what the plug-in is built to do. Microsoft's documentation does not state whether plug-in execution, or the telemetry and logging generated by it, stays strictly inside the customer's tenant. The compute boundary is documented in detail. Microsoft states exactly what a plug-in can call and how that call gets logged. No documentation states whether the sandbox itself sits inside the tenant's assigned region.
What DLP and connector classification can control
Data loss prevention policies classify each connector as Business, Non-Business, or Blocked. Every connector starts in the Non-Business group by default. Connectors in the Business group cannot share data with connectors sitting in Non-Business or Blocked, and that grouping is the actual mechanism DLP uses to keep data from moving between systems it should not touch.
A handful of connectors cannot be blocked at all, regardless of policy. The list includes SharePoint, OneDrive for Business, OneNote Business, Excel Online Business, Microsoft 365 Outlook, Microsoft 365 Users, Microsoft Teams, Dataverse, Approvals, and Notifications. Custom connectors default into the Non-Business group and get reclassified manually, or matched against tenant-level policy by their host URL pattern. Microsoft frames DLP as a guardrail that helps enforce data residency requirements by controlling which connectors are allowed to communicate with each other, so sensitive data does not get moved out of a sovereign region through an unapproved combination of connectors. If your policies were set up before this year, it is worth checking what changed in DLP policy in June before you rely on that classification model here.
That is where the control stops. DLP does not prevent data from leaving the tenant if the connector itself is on the allowed list. It prevents specific connectors from being paired with each other. Microsoft's documentation does not specify whether a DLP policy has any say over data in transit to an external API once that connector is permitted to run, only over which connectors can be combined. Advanced Connector Policies, using a strict allowlist model, add a tighter layer for custom connectors, though today that only covers certified connectors rather than the full range an organisation might build.
Where the documentation stops
Some gaps are worth naming individually rather than folding into the sections above.
Word Online's template population action, the one that fills a Word template with values from a flow, has no documentation stating where that processing physically happens. Microsoft's own connector reference does not say whether the document content is handled inside the tenant or passed through Microsoft's connector infrastructure during that operation. The same silence applies to SharePoint and OneDrive, which move documents in and out of flows constantly and have no documentation stating whether that handling happens inside the tenant boundary either.
More broadly, nothing in the macro region documentation or the connect-data-sources documentation confirms whether the API Management nodes handling connector traffic have to sit in the same region as the customer's Power Platform environment. Microsoft has not published anything stating that data in transit to a connector respects the macro region boundary the same way data at rest does. For multi-geo deployments specifically, Microsoft's own data storage documentation warns that external services configured to access data may cause customer data to be transferred outside the selected geo.
The EU Data Boundary looks like it should settle some of this for European customers, and it settles less than it appears to. It is a real commitment. Microsoft states it will store and process Customer Data and personal data for Azure, Dynamics 365, Power Platform, and Microsoft 365 within a defined set of datacentres across countries including Germany, France, Ireland, and the Netherlands. It only applies when an organisation is provisioned in the EU and EFTA macro region geography and has a billing address in an EU Data Boundary country, both conditions required together. Microsoft's own text also notes limited circumstances where data continues to be transferred outside the boundary regardless. The EU Data Boundary documentation stops short of listing which Power Platform connectors fall inside that boundary and which fall outside it.
If a regulator, an auditor, or a client contract is the reason you need a firm answer about where document data physically travels during generation, get that answer from Microsoft in writing, addressed to your tenant and your scenario, before you build anything on top of an assumption a blog post handed you.