Data Protection in Dynamics 365 Customizations

Data protection is often treated as a process topic in Dynamics projects: consents, contracts, quotes or invoices. Yet part of the requirements is decided much further down, in the configuration of the solution. It is worth looking at the points where customizations and data protection meet, and at what you can read from the solution itself.

Where personal data actually lives

The first duty is knowledge: which tables and fields hold personal data? For the standard tables this is largely known. For custom fields it often is not, and that is where the surprises sleep: the free-text field where health notes have been landing for years, or the remarks field with private phone numbers.

The solution export delivers the complete field list with names, types and descriptions. Even the names say a lot. Fields such as date of birth, private address or other notes about a person belong in the record of processing activities. If their description is empty, nobody will know in two years what they were meant for and what is actually written into them.

Being able to delete, not just wanting to

Who may see which personal data is decided by the role model. There is a separate article on that.

Data subject rights assume that deletion works cleanly on a technical level. This is where configuration gets concrete. Cascade behavior decides whether a contact's activities disappear with it or stay behind as orphans. Required fields and processes that fire on every change can block anonymization runs. Anyone who writes a deletion concept without having read the relationship definitions is merely describing a wish.

Auditing: obligation and risk at once

The auditing function helps with traceability, but it creates a data collection of its own: every change, including old values, stays in the log. Deleting or anonymizing a field does not remove its history. So the data protection concept has to ask what is being audited. That is stated per table and field in the export. It also has to ask how long the logs are kept. That is set in the environment and is not in the export.

Data flows to third parties

Flows with HTTP actions, webhooks, service endpoints, custom connectors: all of these can send personal data to external services. And all of them appear in the export in plain text, for many of these paths including the target addresses. This list of outbound connections is gold for data protection documentation. It is the technical truth behind the question of who receives data. Every target on it should have an entry in the record of processing activities. If it has none, either the entry is missing or the target should be switched off.

An often overlooked outflow path is also in the solution: the security role permissions for Excel exports. If you hold sensitive data in the system but allow every role to export it, you have already given up control over copies outside the system. These permissions can also be counted role by role.

The division of labor

None of this replaces legal work, and this list is not legal advice. But legal work needs the technical inventory as its basis. And that inventory can be drawn from the solution export without touching a single piece of personal data. The export contains the structure without data. That makes it pleasantly uncritical source material for a topic that otherwise turns delicate quickly.