GDPR in Dynamics 365: Retention, Erasure and Data Subject Requests Across Multiple Instances

Who decides what happens to the data, and what does this guide cover?

This is technical guidance on executing requests in Dataverse, not legal advice. Whether a request is valid, which exemptions apply, what must be retained for tax, contract or regulatory reasons and how long you have to respond are decisions for your data protection officer and legal advisers. Involve them before anything is deleted, and get their decisions in writing, because the technical team will need to point to them later.

What the technical team owns is the execution: finding every record reliably, applying the decided action per record without breaking transactional history, and proving it was done. Privacy management platforms handle the request intake and workflow well. The Dataverse execution underneath is where most requests go wrong, and that is what the rest of this page covers.

How do you find every record about one person across several Dynamics 365 instances?

Build a repeatable person search, not an ad hoc Advanced Find. Agree the matching keys with the DPO first, since a weak key finds the wrong people and a narrow one misses records. Then run the same search definition against every environment and the legacy CRM, and log the results per system.

• Matching keys: every email address the person supplied, phone numbers normalised to one format, full name combined with date of birth or postcode, and external identifiers such as customer numbers, portal user IDs or marketing IDs. Name alone is never enough.
• Search tools: Dataverse search gives a quick cross-table first pass where it is enabled, but it only covers tables and columns configured for search. Run FetchXML or Web API queries per table for the definitive result, including every email, phone and name column, not just the primary ones.
• Instances: repeat per production environment, and include sandbox and test copies. A copy made from production carries production personal data until it is reset or scrubbed.
• Legacy CRM: query its database or export with the same keys, and include its attachments store and any archive tables.
• Matching and merging near duplicates of the same person uses the same techniques as our duplicate data cleanup guide; resolve which records are genuinely the requester before acting on any of them.

Which Dataverse tables hold personal data about a person?

More than the contact record. The table below is a starting checklist for a Customer Engagement environment; your own data model adds custom tables, and any table with a lookup to contact or lead, or a free text column where staff type names, belongs on the list.

Should you delete, anonymise or restrict processing?

Choose per record, based on the DPO's decision about which data must be retained. A single request usually uses all three: marketing data deleted, an order history anonymised because the transaction must stay for accounting, and a disputed case restricted until it is resolved.

Why does cascade behaviour decide whether erasure breaks your invoicing?

Every relationship in Dataverse has a delete behaviour, and it decides what happens to the child rows when a parent such as a contact is deleted. Cascade All deletes the related rows too. Remove Link keeps them and clears the lookup, leaving an orphan with no customer. Restrict blocks the delete while related rows exist. Parental relationships cascade by default, referential ones remove the link, and custom configuration can mix both.

So deleting a contact is not one operation. Depending on how each relationship is configured in your environment, it may silently delete the activities and notes regarding that contact, orphan cases so they no longer show a customer, or fail because orders or invoices restrict it. None of those outcomes is what a finance team or auditor expects. Before running erasure, open each relationship from contact and lead to the tables that matter in the maker portal and record its delete behaviour, because customisation and platform updates mean you cannot assume the standard configuration.

The practical rule: where transactional records such as orders, invoices, contracts or regulated cases must be retained, anonymise the contact rather than deleting it. The relationships stay intact, reports still add up, and the person is no longer identifiable. Delete the records that have no retention reason, such as marketing interactions, individually and deliberately.

What happens to personal data held in audit history?

If auditing was on, the change history of a record keeps old values. Anonymising a contact writes new audit entries whose old values are the name, email and phone you just removed, so the erasure is incomplete while that history exists. Deleting the row does not necessarily remove its audit history either.

Dataverse offers ways to delete audit data: deleting the change history of a specific record through the API, and administrator deletion of audit logs by date or table. Which options exist and how they behave has changed over time, so confirm against current Microsoft documentation, test in a sandbox, and agree with the DPO whether the change history for this person should be deleted or retained for another legal reason. Our sibling guide on Dynamics 365 audit trails explains why broad audit deletion destroys evidence and how exported audit copies need the same erasure. For checking what a record's history holds before and after, the free Easy Audit PCF control shows it readably on the form.

How do Customer Insights profiles, portals and copies outside Dataverse affect erasure?

Personal data rarely lives only in the tables you query. Customer Insights - Data builds unified profiles from source systems, so a profile deleted without cleaning its sources returns on the next refresh; erase at source first, then refresh and confirm. Customer Insights - Journeys holds consent and interaction data that needs its own handling. How those are built and connected in your tenant is described on our Customer Insights implementation page, and Microsoft publishes data subject request guidance for its products that you should check for the current method.

Power Pages portal users also exist in the identity provider, which needs its own deletion. Beyond that, list every copy: data lake and warehouse exports, Power BI datasets, integration logs and middleware stores, flow run history, mailboxes synchronised with server-side sync, and SharePoint document libraries. Environment backups cannot be edited record by record; the DPO needs to know that, and restore procedures should reapply completed erasures before a restored environment is used.

How do you set retention policies so erasure requests stop piling up?

Most painful requests are painful because data was kept indefinitely. A retention schedule agreed with the DPO, then enforced automatically, shrinks every future search and removes data nobody should hold. Enforce it in Dataverse with scheduled jobs rather than good intentions.

• Bulk deletion jobs: define the criteria as a query, for example leads not modified since a cut-off date with no qualified status, and schedule the job to recur. Test the FetchXML criteria as a view first and check the count, because the job deletes everything it matches, including through cascades.
• Anonymisation on a schedule: where rows must be kept but identity need not be, a scheduled flow or plug-in that overwrites personal columns after the retention period is safer than deletion.
• Dataverse long-term retention: retention policies can move inactive data out of the live tables into read-only long-term retention, where available for your tables and licensing. It reduces live storage but is still data you hold, so it stays in scope for requests. Check current Microsoft documentation for how retained data is searched and purged.
• Capacity is a side benefit, not the goal. The sibling guide on Dataverse storage capacity cleanup covers the storage view of the same clean up.
• Review the schedule when new tables, integrations or instances are added, so retention keeps pace with the data model.

What evidence proves a data subject request was completed?

A register record that shows what was done without recreating what was erased. Keeping a spreadsheet of the deleted details defeats the purpose. Refer to the person by the request reference and minimal identifiers the DPO approves for the register.

• The request reference, date received, request type and the DPO decision, including what must be retained and why.
• The search definition used: matching keys by type, not the values, and the systems and environments searched, with the date and time of each search.
• Per system: the count of records found per table and the action taken on each group, delete, anonymise or restrict, with timestamps.
• Audit history handling, copies outside Dataverse handled, and anything that could not be erased, such as backups, with the reason.
• Who executed each step and who approved it, by role, and the date the response was sent.

Is Dynamics 365 the right platform for data with strict retention rules?

Usually yes. Dataverse has the relationships, security, auditing and scheduled deletion to execute requests properly; the problems come from configuration that was never designed for erasure. Where your requirements go beyond what configuration can express, such as per field retention across many regimes or erasure built into every workflow, the decision deserves a proper look. We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. A custom-built CRM on React, Node.js, PostgreSQL or .NET can build retention and erasure into the data model from the start, where that fits better than the Microsoft ecosystem.

How does Solzet help with GDPR requests in Dynamics 365?

We build the repeatable parts: a person search that runs across your Dynamics instances and legacy CRM, a documented map of where personal data lives and how each relationship cascades, tested delete, anonymise and restrict routines, audit history handling, retention jobs and the evidence record, all executed to decisions your DPO has made. Where the data and security review should be wider, that is our Dynamics 365 health check and technical audit.

Solzet delivers remotely from Yerevan, Armenia, with senior consultants and full-stack developers and 8+ years of Dynamics 365 Customer Engagement and Power Platform work, directly or white-label for Microsoft partners.