GDPR Data Subject Erasure Flow

Overview

This flow automates GDPR Article 17 (Right to Erasure) compliance end-to-end. When a data subject submits a Microsoft Forms erasure request, the flow searches Salesforce for matching records, routes the request through a legal approval gate, permanently deletes the approved records, writes an immutable audit entry to Dataverse, and confirms outcome to the requester by email.

Trigger: Microsoft Forms — when a new response is submitted Primary Salesforce Action: DeleteItem (target object hard-coded to Contact per FlowLibs schema-binding standard) Audit Log Target: Dataverse custom table flowlibs_gdprerasurelog

Use Case

Regulated organisations must honour GDPR Article 17 requests within 30 days, prove chain-of-custody on deletions, and route the decision through a legal reviewer. Manual handling is high-risk: records get missed, approvals go unlogged, and confirmations don't send. This flow collapses the full workflow into one automation — intake, search, approval, execute, audit, notify — with no human data-handling after submission.

The flow is ideal for teams that:

• Data subject submits a Right to Erasure request via your public-facing Microsoft Form
• Compliance team needs an immutable audit log of every erasure decision
• Legal must sign off before any destructive Salesforce action runs
• Requester must receive automated confirmation (or rejection with reason) within hours, not days

Flow Architecture

Environment Variables

Connectors & Connections

Note — All connections are referenced as solution connection references; the flow is portable between environments as long as a connection is mapped at import time.

Customization Guide

Almost every realistic variant of this flow can be implemented by changing environment variable values. A few cases require small edits inside the flow definition — those are called out explicitly below.

Change the Salesforce target object

Edit Delete_Salesforce_Record and change table from Contact to your target object. Also update the env var flowlibs_SalesforceObjectType default to match. Note: the SOQL FROM clause reads from the env var dynamically; only the DeleteItem table parameter is hard-coded, per FlowLibs standard.

Change the Dataverse audit table

Edit Log_Erasure_To_Dataverse and change entityName from flowlibs_gdprerasurelogs to your target collection logical name. Per FlowLibs standard, this value must be hard-coded at the connector action — never variable-driven.

Add more SOQL fields

Edit Compose_SOQL_Query to add columns to the SELECT clause. Downstream items (email body, audit log notes) reference Name and Email — update those Compose/email body expressions if you rename columns.

Change the approval type

Start_And_Wait_For_Legal_Approval uses approvalType: "Basic". To require multiple approvers, switch to "EveryoneMustApprove" or "FirstToRespond". Update the If condition's outcome string accordingly (Approve for Basic; Approve/Reject at any approver level for parallel types).

Add a retention / cleanup policy

This flow does not delete audit log entries. Pair with a scheduled cleanup flow against

Key Expressions

The flow is intentionally light on Power Fx / WDL gymnastics — the heaviest expressions are the branch-name concatenation and the approval outcome check. They are listed below in the order they appear in the flow.

@{coalesce(outputs('Get_Erasure_Request_Response_Details')?['body/responder'], 'unknown@unknown.com')}

@{concat('SELECT Id, Name, Email FROM ', variables('varSalesforceObject'), ' WHERE Email = ''', outputs('Compose_Requester_Email'), '''')}

@{length(coalesce(outputs('Search_Salesforce_For_Matching_Records')?['body/records'], createArray()))}

@{coalesce(outputs('Start_And_Wait_For_Legal_Approval')?['body/responses'][0]['comments'], 'No comments provided')}