Product documentation
Personal data is any information that relates to an individual who can be directly or indirectly identified. Names and email addresses are obviously personal data. Location information, ethnicity, gender, biometric data, religious beliefs, web cookies, and political opinions can also be personal data. Pseudonymous data can also fall under the definition if it’s relatively easy to ID someone from it.
Effective data anonymization is made up of two parts:
Removing directly identifying elements in itself is not enough to ensure that identification of the data subject is no longer possible. It will often be necessary to take additional measures to prevent identification, once again depending on the context and purposes of the processing for which the anonymized data are intended.
When a DPO receives a request to anonymize a contact record, the DPO will search for the contact record and select the Flow button in the ribbon bar of the contact record.
After confirmation of the dialog box a workflow will be triggered to execute the anonymization process which will convert specific contact data to anonymized values. The anonymization will take place based on the definitions in the Anonymization Settings and Anonymization Setting Value entities.
The anonymization process will mark all active data consent records to inactive, to ensure that there are no active data consent records linked to the anonymized contact anymore. The status reason of the data consent record(s) will be set to Anonymized. Further, relevant fields are anonymized, field Data Protection Consent is set to Restrict, field Consent Level is set to (0) None and the Contact Preferences fields to Do Not Allow. The field Maximum Expiry Date will be cleared when the calculated field is recalculated again, which happens on a daily basis.
Based on Business Unit parameters Delete Audit History, Delete Contact and Lead Posts and Delete Opportunity Posts several related delete actions will be performed in order to anonymize the contact record completely.
Last but not least it is captured who triggered the anonymization process and when the anonymization was performed.
The following views have been defined for contacts:
| View | Description |
| Data Protection Active Contacts | A list of all active contacts. |
| Data Protection All Contacts | A list of all active & inactive contacts. |
| Data Protection Anonymized Contacts | A list of all anonymized (inactive) contacts. |
| Data Protection Contacts Missing Consent | A list of all active contacts that do not have an active data consent. |
| Data Protection Inactive Contacts | A list of all inactive contacts (excluding anonymized contacts). |
The lead anonymization process has exactly the same principle as contact anonymization process. Of course the lead entity has its own Anonymzation Settings setup, meaning different fields could be defined for anonymization, but triggering the anonymization is performed the same way.
When a lead is qualified the user has a choice to convert the lead to a contact. When that happens the existing active data consent(s) of the lead will be linked to the contact as well. Further, in the new contact, the fields Data Protection Consent and Consent Level will be updated based on the data consent(s).
If a contact is anonymized which was originally created via a qualified lead, the lead will be anonymized automatically. The other way around is not possible, if a DPO is trying to anonymize a lead that has one or more active contacts linked, an error message will be thrown. The DPO should then trigger the anonymization via the contact anonymization.
The following views have been defined for leads:
| View | Description |
| Data Protection Active Leads | A list of all active leads. |
| Data Protection All Leads | A list of all active & inactive contacts. |
| Data Protection Anonymized Leads | A list of all anonymized (inactive) leads. |
| Data Protection Disqualified Leads | A list of all disqualified leads. |
| Data Protection Leads Missing Consent | A list of all active leadss that do not have an active data consent. |
| Data Protection Qualified Leads | A list of all qualified leads. |
As described earlier from Dynamics Data Protection version 2.0 and onwards it is allowed to create anonymization settings for any entity. The solution contains two out of the box anonymization workflows, one for entity Contact and one for entity Lead.
If for example it is required to be able to anonymize an account, an Anonymization Settings record for entity Account should be created first, including the Anonymization Setting Values of this entity.
Secondly, a new workflow should be created (and activated) in order to be able to trigger the anonymization process.
Create a new workflow for the entity that requires anonymization and make sure to set the following values:
Add a step and select from HDS.Dynamics.GDPR.Workflows the step HDS.Dynamics.GDPR.Workflows.Anonymization.AnonymizeEntity. This step will take care of anonymizing the fields that are defined in the Anonymization Setting Values for the entity.
If it is required to set the Status and Status Reason of the anonymized record to a certain value, it is necessary to add an additional step in the workflow.
Add a second step and select from HDS.Dynamics.GDPR.Workflows the step HDS.Dynamics.GDPR.Workflows.Entities.ManageEntityState. This step will take care of setting the fields Status and Status Reason to a value that is defined in the Anonymization Setting Values for the entity.
Last but not least make sure you activate the workflow.
It should then be possible to select the workflow as an on demand workflow from any record in the specified entity (in this example entity Account).
