Product documentation
In This Topic
    Dynamics Data Protection - Settings
    In This Topic

    In this topic the basic setup for Dynamics Data Protection will be explained. In the Data Protection app, the area Settings is available. Via this menu it is possible to access the different setup entities that are part of the Dynamics Data Protection solution.

    In the next paragraphs the Settings entities are described.

     

    Data Protection > Settings > General Settings

    General Settings

    Anonymization Settings

    The entity Anonymization Settings needs to be defined as a prerequisite for being able to anonymize records for a specific entity.

    Note that it is only allowed to define one unique record per entity.

    From Dynamics Data Protection version 2.0 and onwards it is allowed to create anonymization settings for any entity. By default the solution delivers anonymization workflows for entity Contact and Lead. If for example an anonymization settings record is created for entity Account, still in the project implementation, a specific workflow for anonymization of Accounts needs to be implemented. For instructions how to implement a workflow which is not delivered out of the box, click here.

     

    Anonymization Setting Values

    When i.e. the contact or lead entity has been defined in anonymization settings, it is necessary to define the Setting Values of the entity in order to be able to anonymize a record. Via the Setting Values each field that requires anonymization can be setup in a specific format that is used when a record is being anonymized.

    Note that the setting values (fields) of the entity forms are automatically added when an anonymization setting record is created (except fields like created on, created by, modified on, modified by and ownerid).

     Important

    Note that almost all attributes of an entity are automatically loaded into the setting values. It is highly recommended to remove all the attributes that do not require anonymization. This will improve the performance of the anonymization workflows.
       

    For each setting value the fields Attribute Name and Attribute Value Type must be defined. The field Anonymize Value is mandatory when attribute type Two Option, Status or Status Reason is selected. Once defined, the record definitions will be used by the anonymization workflow. Note that it is also possible to 'clear' a value of a field by leaving the field Anonymize Value as <blank>.

    When defining a field with attribute value type Option Set, it is required to use the exact technical value as defined in the Option Set and fill that value in the field Anonymize Value.

     Important

    Note that it is possible to set the anonymize value for an Option Set to a <blank> value. However, if an Option Set is defined as business required in the form, you must specify an anonymize value in the setting value otherwise the anonymization workflow will empty a field which is business required.
       

    Last but not least, for attribute value types Single Line Of Text and Multiple Lines Of Text it is possible to set the value Allow Random Value to Yes. When selecting that option, additional fields will be visible and become business required. The effect of these settings is that the field is anonymized in a random way, depending on the selected values for random anonymization.

    Field Description
    Attribute Name

    The logical name of the field that needs to be anonymized.

    Attribute Value Type

    The following type of fields are supported for anonymization: Currency, Customer, Date Time, Decimal Number, Floating Point Number, Lookup, Multiple Lines Of Text, Option Set, Single Line Of Text, Status, Status Reason, Two Options and Whole Number.

    Anonymize Value Anonymize value which is depending on the attribute value type field.
    Allow Random Value Is a random value allowed (only available for Single Line Of Text and Multiple Lines Of Text).
    Random String Type Values: Random String, Random Number and Random Mix (a combination of both string and number).
    Random String Length Define the random string length which should be a number between 4 and 12.
    Random String Position Values: Prefix or Suffix
    String Casing Values: Upper Case, Lower Case & Proper Case. This field is not visible if type Random Number is seleted. 

    Status and Status Reason

    Dynamics Data Protection comes out of the box with two workflows in order to anonymize contacts and leads. Initially these workflows did automatically set the Status and Status Reason of an anonymized contact to Inactive and Inactive and for an anonymized lead to Disqualified and Canceled.

    As it is now possible to anonymize any entity, the value of the fields Status and Status Reason has been implemented in the setting value definition of an entity's anonymization setting. The reason is that each entity can have different values of Status and Status Reason and it will become more complex to define these values in entity specific workflows.

    Therefore it is now required to add the Status and Status Reason fields in the setting values of the anonymization entity, only if it is required to set specific values for those fields upon anonymization of a record. We do however recommend to set the value of Status and Status Reason for anonymized records to 'Inactive' in a production environment.

    For a lead the value for Status is 2 (Disqualified) and the value for Status Reason is 7 (Canceled) as shown below.

     For a contact the value for Status is 1 (Inactive) and the value for Status Reason is 2 (Inactive) as shown below.

     Note

    A list of values of Status and Status Reason for most relevant standard Microsoft entities can be found here.
       

     

    Data Protection > Settings > Data Management Settings

    Data Management Settings

    Data Subject Types

    The entity Data Subject Types is used to define different types of Data Subjects to be used in the Data Processing Activities form. The type is the target group for which the personal data is being taken from.

     

    Personal Data Types

    The entity Personal Data Types is used to define different types of Personal Data to be used for data processing in the Data Processing Activities form. The different types of data that would make it easy for a person to be identifiable.

    Personal data means any information relating to an identified or identifiable natural person (data subject). An identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.

     

    Departments Processing Data

    The entity Departments Processing Data is used to define different types of Departments to be listed in the Data Processing Activities form as internal data processors.

     

    Data Processing Tools

    The entity Data Processing Tools is used to define Data Processing Tools (name of the IT system or software) used to process data to be indicated in the Data Processing Activities form. The Owning Business Unit has been added to the views in order to show who the owner is of the data processing tool. The data processing tool is also mentioned on the data consent report so when data needs to be removed from the system, the DPO and DPC can easily identify who the owner is.

     

    Data Protection > Settings > Other Settings

    Other Settings

    Data Protection Case Types

    The entity Data Protection Case Types is used to define different types of Data Protection Cases and can be used to categorize Data Protection Cases. The Data Protection Case Type is also used in the Data Protection Cases Dashboard.

     

    Data Protection Case Type Priorities

    The entity Data Protection Case Type Priorities is used to define maximum three SLA's per Data Protection Case Type. An SLA can be defined for each Case Priority (Low, Normal and High) and is defaulted when the Data Protection Case Type and Priority is selected in a Data Protection Case. It is also possible to default a Priority on case creation after selecting a Data Protection Case Type.

     

    Consent Level Substatuses

    The entity Consent Level Substatuses is used to define the substatuses of the out of the box consent level values.  When the field Default is set to yes, the consent level substatus will be defaulted when a data policy is created. Further, when a data consent is created, the consent level substatus from the selected data policy is then copied to the data consent and can still be changed afterwards.

     

     

    Knowledge Articles

    The standard entity Knowledge Articles is used to store Data Protection Articles that can be linked to a Data Protection Case.

    When one or more Data Policies are linked to a Knowledge Article it is considered being a Data Protection Knowledge Article and will be visible in the Data Protection Knowledge Article views.

     Note

    Note that a Data Policy can only be linked to one Knowledge Article and the Data Policy should be published in order to see the link on the Knowledge Article. Removing the Knowledge Article in a Data Policy will also clear the link on the Knowledge Article.
       

     

    Data Protection > Settings > Security Settings

    Security Settings

    Business Units

    Business units listed in this view can be enabled for Data Protection anonymization.

     

    Teams

    A team is a group of users who share and collaborate on business records. A user can be associated with multiple teams.

     

    Users

    Dynamics 365 Customer Engagement provides an overview of users who can be licensed to use the Data Protection app.

     

    Security Roles

    There are four security roles delivered with the Dynamics Data Protection solution:

    Field Description
    App Access Gives access to the Data Protection App.
    Data Protection Coordinator The DPC role is like a DPO however should only see data for its own and child business units. The role enables them work on Data Protection cases and assist the DPO in managing Data Protection in the organisation.
    Data Protection Officer The DPO should be have all access rights in the Data Protection App for the dashboards, data consents, data policies, data processing activities, tasks, cases, forms, views so that they can manage all the Data Protection requirements from the App.
    Data Protection User The DPU role should enable users to create data consents and data contracts and only have access to view any other Data Protection entities and Data Protection Cases.