This repository contains files and general instructions for creating a basic Data Subject Request tracker using Microsoft Power Automate. The tracker is made up of two flows. The specific requirements and configuration for each flow are contained in the README of each flow's folder along with the files you can use to import the flow into your own environment. These flows were created using Microsoft Power Automate and some familiarity with various aspects of Microsoft (MS) Sharepoint - specifically Forms, Lists, and Approvals - is helpful for replicating or modifying the tracker yourself.
- Microsoft Power Automate
- Uses: Microsoft Forms, Outlook, Teams, and SharePoint.
Data Subject Requests (or Data Subject Access Requests) are required by various privacy laws. They allow an individual to access information about their personal data and how an organization is managing those data. This is generally for the purposes of understanding what data are held, updating the data, or asking the organization to delete their data. At Mercy Corps, such a request requires coordinating with the owners of 11 different information systems and my team needed a relatively easy way to track these requests.
The initial "system" that was developed for these was simply to receive a request via an email, then email all the system owners at regular intervals to comply with the request. There were several problems with this and the system was:
- unresponsive to data subjects who didn't get an immediate response;
- inefficient: clogged inboxes, searching for emails, etc;
- difficult to track and hard to see who has complied with what;
- difficult to report on, since any audit trail would require searching through and stitching together multiple emails;
- insecure because emails containing personal information related to the request could stay in people’s inboxes.
The solution presented here uses a Form, a List, and Power Automate to create a more secure, more efficient system based on a two-part workflow.
The first flow takes input from a form and creates a new item in a Sharepoint list, which in turn notifies the "DSAR owner" (person responsible for managing requests) that a new item has been created. The flow also sends an automated email to the requestor informing that the request has been received. Below is a diagram of Flow 1.
In the flow I've created, the DSAR owner manually reviews the request and then continues the flow (in Part 2, below) by updating the request. This step could also be part of the flow, but it was easiest for me to simply review the list manually and update each item at regular intervals.
Upon reviewing the request and deciding to proceed, the DSAR owner updates the status of the list item from New to Approved, which triggers an approval to multiple system owners. System owners receive an Approval via both email and as a Teams message. The system owner can simply click the appropriate response type, add a comment, and submit. This automatically updates the list item with whatever response was taken. The approval I've created allows for 3 types of response:
- The data subject was not found in the system.
- The data subject was found and deleted from the system.
- The data subject was found in the system but was not deleted (e.g. due to legal hold, data retention policies, etc.)
You can create whatever response types you need.
This allows the DSAR owner to track the status of all requests across all systems. The actions of each system owner are captured in the Microsoft Approvals history in case an audit trail is required. Membership to the Sharepoint lists that holds the requests can be easily managed to limit access to only those who need it and the fact that Approvals transform from a request to a receipt once the request is complete, means that no personal information remains inadvertently inside of emails.
Below is a diagram of Flow 2.
There are two primary changes that should be considered for this flow. The first is to combine them. I've purposefully created a two-step process to force myself to interact with the list that contains requests, but you could easily introduce an approval to flow 1 in which the DSAR owner would approve the incoming request and that approval would kick off flow 2.
The other improvement would be to generate an automatic email to the requestor once all system owners have responded. I've purposefully kept this manual since I may want to alter my correspondence with the requestor based on how the system owners comply, but this could be automated as well.
I found the following extremely helpful for developing my flow:
- Create your first flow
- Microsoft Power Automate documentation
- This walk-through for creating a Simple Ticketing System in SharePoint Online is what got me started thinking about managing DSRs in a List versus the current spreadsheet workflow.
- This sample request/review/approval flow from the the M365 user community
- A Power Automate template from Microsoft or the larger library of Power Automate templates
- Documentation from Microsoft outlining parallel approvals and how to package Power Automate flows for sharing, import, and export.