Power Automate and AVG/GDPR: Stop Your Flows Quietly Copying Personal Data

The scenario: HR ticketing flow that grew out of control

Imagine an HR team using Microsoft 365 and Power Automate:

• HR requests come in via a Microsoft Forms form.
• A flow writes responses to a SharePoint list, sends the details to the HR mailbox, and notifies the assigned HR officer.
• Over time, people added steps: copying attachments to personal OneDrive, sending notifications to private Gmail accounts, pushing data into a third‑party helpdesk via connector.

Data involved:

• Names, email addresses, phone numbers.
• Sensitive data (health issues, performance problems) in free‑text fields.
• Attachments: medical letters, contracts, disciplinary notes.

The privacy officer asks a simple question: “Which flows copy personal data outside our tenant, and under what legal basis?”

You realise:

• There is no central view of where flows send data.
• Many flows run under individual users’ connections.
• Nobody checked which connectors are considered data transfers outside the organisation.

Let’s clean this up systematically.

Step 1 – Identify where personal data actually flows

Before you fix anything, you need to know which flows touch personal data and where they send it.

1.1 Classify the HR flow

Walk through the HR scenario and identify:

• Sources: Microsoft Forms responses, SharePoint list items, email messages, attachments.
• Destinations:
  • Shared HR mailbox (Exchange Online).
  • SharePoint site owned by HR.
  • Personal OneDrive of individual HR officers.
  • Gmail accounts of HR officers.
  • Third‑party helpdesk via connector.

Under AVG/GDPR, the risk is mainly in:

• Personal storage (personal OneDrive, personal mailbox).
• External services not under your organisation’s Microsoft 365 or DPA (e.g. consumer Gmail, unsupported SaaS tools).

1.2 Use environment and solution views

As of late 2026, the practical ways to see where data flows in Power Automate are:

• Power Automate portal (per environment)

  • Go to Power Automate → My flows / Team flows.
  • Select the environment used by HR from the environment picker.
  • Open each flow that references HR data sources (Forms, HR SharePoint, HR mailbox).
  • Check the Connections pane and each action’s connector.

• Solutions (Dataverse environments)

  • If flows are in solutions, open the solution in the Power Apps or Power Automate portal.
  • Inspect each cloud flow and its connectors.

You’re looking specifically for:

• OneDrive for Business actions where the connection owner is an individual user.
• Outlook.com or Gmail connectors (consumer or personal accounts).
• Third‑party connectors (e.g. Trello, Zendesk, custom APIs) used with HR data.

Document each flow:

• Name and environment.
• Trigger (Form, SharePoint, email).
• All destinations that might store personal data.

This gives you a concrete list of flows that need privacy hardening.

Step 2 – Understand AVG/GDPR risk patterns in Power Automate

Power Automate itself doesn’t “know” about AVG. It just executes connectors with whatever data you pass. The risk comes from how you design flows and which connections you use.

For the HR scenario, the main patterns to watch:

2.1 Personal vs organisational storage

Risky patterns:

• Copying HR attachments to personal OneDrive using the OneDrive for Business connector with a user’s personal drive as the target.
• Forwarding HR emails to personal mailboxes (Outlook.com, consumer Gmail) via connectors.

Privacy‑friendly alternatives:

• Use SharePoint sites or OneDrive folders owned by a shared account or security group.
• Keep data within Exchange Online organisational mailboxes.

2.2 External SaaS connectors

Any connector that sends data to a third‑party service is a potential data transfer:

• Some connectors are Microsoft‑owned and stay within Microsoft’s cloud.
• Many are for external services (e.g. Dropbox, Slack, Zendesk) under separate terms.

For AVG/GDPR:

• You need a legal basis and, often, a data processing agreement with the external provider.
• You should avoid sending special category data (health, union membership, etc.) unless explicitly allowed and necessary.

2.3 Who owns the connections

Each connector action runs under a connection created by a user or service principal.

Risks:

• Flows running with personal user connections may stop working when the user leaves or their account changes, and may be harder to reassign.
• Harder to audit which identities have access to HR data.

Better:

• Use service accounts or managed identities where available.
• Use connection references in solutions to centralise connection management.

Step 3 – Design privacy‑friendly flows for HR data

Now we redesign the HR flow to keep personal data inside the tenant and under control.

3.1 Keep storage shared, not personal

Current risky step:

• "When a new response is submitted" (Forms) → "Get response details" → "Create file" in OneDrive in the HR officer’s personal drive.

Safer design:

• Create files in a HR SharePoint document library or a OneDrive folder owned by a shared account.

Example structure:

• SharePoint site: HR-Requests.
• Library: SensitiveRequests with restricted permissions.

Flow change (conceptual):

1. Trigger: When a new response is submitted (Forms).
2. Action: Get response details.
3. Action: Create item in HR-Requests SharePoint list with metadata.
4. Action: Create file in SensitiveRequests library for attachments.

No code is needed here, but the key is:

• Use the SharePoint connector with a connection owned by a service account or managed identity.
• Avoid any OneDrive action that targets a user’s personal drive.

3.2 Replace personal email with organisational channels

Current risky step:

• "Send email" using Gmail connector to HR officer’s personal Gmail.

Safer alternatives:

• Use Office 365 Outlook (Exchange Online) to send to:
  • HR shared mailbox (hr@company.nl).
  • Distribution lists (hr-team@company.nl).

Design:

1. After creating the SharePoint item, use Send an email (V2) from Office 365 Outlook.
2. Include only necessary fields in the email body.
3. Avoid attaching full documents if the mailbox is broadly accessible; instead, link to the restricted SharePoint item.

Example email body (conceptual):

• Subject: New HR request: @{triggerOutputs()?['body/employeeName']}
• Body: A new HR request has been submitted. View details: <SharePoint item link>

This keeps personal data within Exchange Online and SharePoint, which are already under your organisation’s control and policies.

3.3 Control external connectors

If HR really needs to push data into a third‑party helpdesk:

• Limit the fields sent (minimise personal data).
• Avoid sending attachments with sensitive content unless absolutely needed.
• Store the full record in SharePoint; send only a reference ID and non‑sensitive summary to the external tool.

Flow pattern:

1. Create full record in HR SharePoint list.
2. Generate a unique request ID (e.g. using a GUID or list item ID).
3. Call the external connector with:
   • Request ID.
   • High‑level category (e.g. "Payroll question", not "Health complaint").
   • Link back to SharePoint (only accessible inside tenant).

This satisfies the operational need while reducing the volume of personal data leaving your environment.

Step 4 – Use environments and DLP to enforce privacy

Designing one flow correctly is not enough. You need guardrails so future flows don’t reintroduce the same AVG/GDPR issues.

4.1 Separate environments for sensitive workloads

Use Power Platform environments to separate sensitive flows:

• Create a dedicated HR environment.
• Restrict who can create flows there.
• Put all HR flows in that environment and, ideally, in managed solutions.

Benefits:

• Environment‑specific Data Loss Prevention (DLP) policies.
• Clear scope for audits and access reviews.

4.2 Configure DLP policies for connectors

In the Power Platform admin center, define DLP policies that classify connectors:

• Business group: Connectors allowed for HR data (SharePoint, Office 365 Outlook, Forms, Teams, etc.).
• Non‑business group: Connectors allowed for non‑sensitive use.
• Blocked: Connectors not allowed at all for HR.

For the HR environment:

• Put Gmail, Outlook.com, and consumer cloud storage (Dropbox, Google Drive) in Blocked.
• Put HR‑relevant Microsoft 365 connectors in Business.
• Put general external SaaS connectors in Non‑business or Blocked, depending on your policy.

Effect:

• If someone tries to build a flow that sends HR data to Gmail, the flow cannot be saved or run because of the DLP policy.

This is one of the most effective technical controls for Power Automate privacy.

4.3 Connection references and service accounts

In solutions:

• Use connection references so flows don’t each carry their own ad‑hoc connections.
• Create connections using service accounts or managed identities where supported.

Benefits:

• Central management of which identity accesses HR data.
• Easier to rotate credentials and review access.

Step 5 – Minimise personal data inside each flow

Even inside your tenant, AVG/GDPR expects data minimisation.

For the HR flow:

5.1 Avoid copying full payloads everywhere

Common anti‑pattern:

• Each action copies the full Forms response JSON or entire SharePoint item, even if only one field is needed.

Better:

• Map only required fields into downstream actions.
• Use IDs and links instead of duplicating sensitive text.

Example pattern:

• Store full details only once in a restricted SharePoint list.
• Use the list item ID in Teams notifications, emails, and external calls.

5.2 Use conditional logic to separate sensitive paths

If some HR requests are more sensitive (e.g. health‑related):

• Add a category field in the form.
• In the flow, branch based on category:
  • Sensitive: store in SensitiveRequests library, notify only senior HR.
  • Non‑sensitive: store in standard library, notify broader HR group.

This keeps sensitive data away from broader channels while using the same core flow.

5.3 Implement retention via scheduled flows

AVG/GDPR also cares about not keeping data forever.

Pattern:

• Create a scheduled cloud flow that runs daily or weekly.
• It queries the HR SharePoint list for items older than your retention period.
• It either deletes them or moves them to an archive with stricter access.

Design points:

• Use filters on date fields (e.g. created date).
• Log deletions or moves in a separate audit list.

This keeps retention under control without manual clean‑up.

Step 6 – Make privacy visible to the team

Technical controls work best when the HR team understands them.

For the HR scenario:

• Document the data flow: Forms → HR SharePoint → HR mailbox → (optional) external helpdesk with limited fields.
• Maintain a simple register of flows that touch personal data:
  • Name, owner, environment.
  • Connectors used.
  • Types of personal data processed.
  • Destinations outside the tenant.
• Give HR admins a checklist for new flows:
  • Does this flow touch personal or sensitive data?
  • Are all connectors allowed by DLP?
  • Are we sending data to personal storage or external SaaS?
  • Can we minimise fields or use IDs instead?

This turns privacy from a one‑off project into a normal part of how you design automation.

Practical takeaway

Next time someone mentions "Power Automate privacy" or "Power Automate GDPR", don’t start with theory. Start by listing flows that touch personal data, check where they send it, and lock down personal and external destinations with environments and DLP. If you can keep HR‑style flows inside shared Microsoft 365 resources, minimise what leaves the tenant, and centralise connections, you’ve already eliminated most of the silent AVG/GDPR risks in your automation.