Where Does Your Flow’s Data Live? RODO, the EU Data Boundary and Power Automate

Scenario: HR automation under RODO pressure

You’re automating HR onboarding for a Polish company:

• Employee data comes from Dataverse tables and SharePoint lists.
• Flows send onboarding emails, create accounts, update payroll systems.
• IT security has one hard requirement: all personal data must stay in the EU/EFTA where possible.

The tenant was created in an EU datacenter, but:

• Some environments were created by different teams over the years.
• A few flows use AI Builder and third‑party connectors.
• Finance changed the billing address after a merger.

The question: Does this setup actually fall under the Microsoft EU Data Boundary, and where does Power Automate process and store data?

What the EU Data Boundary actually covers

Microsoft’s EU Data Boundary is a contractual and technical commitment that, under specific conditions, customer data for core Microsoft 365, Dynamics 365, and Power Platform services is processed and stored within the EU/EFTA.

For Power Platform, the key points relevant to Power Automate are:

• It is conditional, not automatic. You only fall within the EU Data Boundary if:
  • Your tenant is provisioned in an EU/EFTA macro‑region.
  • All relevant environments (Power Platform environments where your flows run) are in EU/EFTA regions.
  • The billing address for your tenant is in an EU or EFTA country.
• It applies to customer data in covered services. For Power Automate this includes:
  • Flow definitions and run history stored in Dataverse / Power Platform infrastructure.
  • Data processed by standard Microsoft connectors within covered services (e.g. SharePoint Online, Exchange Online, Dataverse).
• It does not magically move third‑party systems into the EU. If your flow calls a SaaS API hosted in the US, that external processing is outside the boundary.

For our HR onboarding scenario, you only get the EU Data Boundary assurance if:

1. The tenant is in an EU region.
2. Every environment used by HR flows is hosted in EU/EFTA.
3. The tenant’s billing address is in an EU/EFTA country.

Any deviation breaks the full EU Data Boundary assumption for those flows.

Power Automate data: what is stored where?

When you design or run a flow, Power Automate touches several types of data. From a RODO perspective, you need to know which ones may contain personal data and where they live.

1. Flow definition and configuration

Includes:

• Trigger and action configuration
• Connection references
• Environment variables
• Expressions and inline values

Storage:

• Stored in the Power Platform environment (Dataverse / flow service) in the region of that environment.

Implication:

• If the environment is in an EU/EFTA region and your tenant/billing meets EU Data Boundary conditions, this configuration data is covered by the boundary.

2. Flow run history and logs

Includes:

• Input and output payloads for actions
• Error messages
• Correlation IDs and system logs

Storage:

• Stored in the same environment region as the flow.
• Retention is configurable per environment or per flow (depending on setup and licensing), but location is tied to the environment region.

Implication:

• If your flow processes personal data, that data may be present in run history.
• Keeping environments in EU/EFTA and avoiding non‑EU actions keeps this history inside the boundary.

3. Connector data movement

Connectors are where most RODO questions arise. For Power Automate:

• Microsoft 365 connectors (SharePoint, Outlook, Teams, etc.)
  • Data is processed in the region of the underlying service (e.g. your SharePoint Online region), which for an EU tenant is typically EU.
• Dataverse connector
  • Data is processed in the Dataverse environment’s region.
• Azure connectors (Storage, Functions, Service Bus, etc.)
  • Data location depends on the target Azure resource region, which you choose when creating those resources.
• Third‑party connectors (Salesforce, ServiceNow, custom APIs)
  • Data leaves Microsoft’s boundary and is processed where the third‑party service is hosted.

Implication:

• The EU Data Boundary covers Microsoft’s handling of data inside its services.
• It does not guarantee EU location for:
  • Third‑party SaaS backends
  • Custom APIs hosted outside EU/EFTA

4. AI and advanced processing features

Some features may process data differently:

• AI Builder and related models
• Copilot experiences within Power Automate

As of the EU Data Boundary rollout, Microsoft is progressively aligning these features with the boundary, but capabilities may differ by region and feature.

Implication:

• For HR data, treat AI features as a separate risk assessment.
• Check current documentation for each AI feature to confirm whether its training and inference data are constrained to EU/EFTA under the boundary.

The three conditions: tenant, environments, billing

The core fact for Power Platform and Power Automate:

Power Platform falls within the EU Data Boundary only when the tenant and all environments are in the EU/EFTA macro‑region and the billing address is in an EU or EFTA country.

Let’s unpack what can go wrong in the HR scenario.

1. Tenant region mismatch

If the tenant was originally created in a non‑EU region, even if you later create EU environments, you don’t get full EU Data Boundary coverage for the tenant.

Check:

• Use the Microsoft 365 admin center to confirm the tenant’s primary data location.

If it’s not EU/EFTA:

• You can still design flows that keep data in EU‑hosted services, but you don’t have the formal EU Data Boundary commitment for tenant‑level data.

2. Environments outside EU/EFTA

Common pattern:

• Default environment in EU.
• A dev/test environment created in a non‑EU Azure region by a global team.
• HR flows accidentally deployed there.

Result:

• Flow definitions and run history for those HR flows are stored in that non‑EU region.
• Any Dataverse tables in that environment are also non‑EU.

Check:

• In Power Platform admin center, verify Region for each environment used by HR.

Fix:

• Create dedicated HR environments in EU/EFTA regions.
• Move flows and data to those environments.
• Restrict environment creation for sensitive workloads to EU/EFTA regions via governance.

3. Billing address outside EU/EFTA

Less visible but critical:

• After a merger, the tenant billing address is changed to a non‑EU country.

Result:

• Even if the tenant and environments are in EU/EFTA, the EU Data Boundary conditions are no longer fully met.

Check:

• In Microsoft 365 admin/billing portal, confirm the billing address country.

Fix:

• Work with finance/procurement to align billing address with the legal entity that requires RODO compliance.
• Document this in your data protection impact assessment (DPIA).

Designing flows that respect RODO and the EU Data Boundary

Back to the HR onboarding flows. Assume you’ve confirmed:

• Tenant: EU region
• All HR environments: EU/EFTA
• Billing address: Poland

Now you want to make sure the flows themselves don’t break your data‑location assumptions.

1. Keep personal data in EU‑hosted services

When choosing where to store and process HR data:

• Prefer:
  • Dataverse in EU environments for structured HR tables.
  • SharePoint Online sites in EU regions for documents.
  • Exchange Online mailboxes in EU regions for notifications.
• Avoid:
  • Sending personal data to non‑EU Azure regions.
  • Using connectors that route data to SaaS platforms hosted outside EU/EFTA unless contractually covered.

Practical pattern:

• Use Dataverse tables in an EU HR environment for:
  • Employee master data
  • Onboarding tasks
  • Audit logs

2. Minimise personal data in flow run history

Even within EU, RODO pushes you to reduce unnecessary data storage.

Patterns:

• Avoid putting full personal payloads into:
  • Compose actions
  • Variables used only for logging
  • Custom traces
• Use IDs and references instead of full records where possible.

Example: instead of logging the full employee object, log only the employee ID and status.

(This is a conceptual pattern, not actual Power Automate code.)
Good logging pattern: store minimal identifiers such as EmployeeId, Status, and Timestamp
rather than full personal data. In Power Automate you implement this via Compose actions
and by writing minimal fields to Dataverse or other logging stores.

(The snippet above illustrates the pattern of storing minimal identifiers; in Power Automate you’d implement this via Compose actions and Dataverse rows.)

3. Be deliberate with connectors that cross borders

For each connector in your HR flow:

• Identify whether the backend service is:
  • Microsoft 365 / Dataverse in EU
  • Azure resource in a specific region
  • Third‑party SaaS with its own data centers

Governance steps:

• Maintain a connector registry indicating:
  • Data location of the backend
  • Whether use is allowed for personal data
• Use DLP policies in Power Platform admin center to:
  • Block connectors that send HR data to non‑EU services.
  • Separate business and nonbusiness connectors.

4. Treat AI features as a separate risk decision

For HR data under RODO:

• Don’t enable AI Builder or Copilot on sensitive flows without:
  • Confirming current data‑location behaviour in Microsoft documentation.
  • Updating your DPIA and records of processing activities.
• If you use AI, prefer scenarios where:
  • Input data is minimised.
  • Outputs don’t include full personal profiles.

Explaining this to your DPO and IT approver

You’ll often need to translate Power Automate and EU Data Boundary behaviour into language your DPO understands.

For the HR onboarding scenario, a clear explanation might look like:

1. Location of processing

   • All HR flows run in Power Platform environments hosted in EU data centers.
   • Under the EU Data Boundary, Microsoft commits to processing and storing customer data for these services within EU/EFTA, given our tenant and billing configuration.

2. Systems involved

   • HR data is stored and processed in Dataverse, SharePoint Online and Exchange Online, all in EU regions.
   • No third‑party connectors are used for personal data without separate contracts.

3. Logging and retention

   • Flow run history is stored in the same EU environments.
   • Logs are configured to store only the minimum data needed for troubleshooting.
   • Retention policies are aligned with HR and legal requirements.

4. Exceptions and limitations

   • Any future use of AI features or new connectors will be assessed separately.
   • If the tenant, environment regions, or billing address change, the EU Data Boundary assumptions will be re‑checked.

This gives approvers a concrete view of where data lives and why the design is compliant.

One practical takeaway

For RODO‑sensitive Power Automate solutions, treat tenant region, environment region and billing address as hard architectural constraints, not paperwork. Before building flows, lock down where your environments live, enforce EU/EFTA‑only regions for personal data workloads, and document how each connector handles data so you can answer the “Where does this data live?” question with confidence.