GDPR – Process and Data source configuration

Facebooktwittergoogle_pluspinterestlinkedinmail
Applies to version 2017.1.3.x; Author: Bartłomiej Spyrka

Configuring processes, form fields, and data sources to interact with GDPR-related features in WEBCON BPS

1. Introduction

This article shares configuration methods of a system based on WEBCON BPS while adhering to GDPR regulations.

In this article you will learn:

  • What personal data dictionaries are in WEBCON BPS
  • What are the types of personal data dictionaries and how to configure them
  • How to designate the content of specific processes as sensitive data
  • How to generate a report presenting personal data usage in WEBCON BPS

It is important to notice, that GDPR introduces new guidelines for personal data protection, but does not impose strict rules that must be adhered to in a specific company. This following solution is not a complete blueprint but only serves as an example. You can base your own configuration on it so that your company works in accordance with GDPR ruling.

 


 

2. Personal data sources – configuration

2.1. Description

This chapter will provide examples of personal data source creation, available in WEBCON BPS for adjusting to GDPR.

There are two types of personal data sources in BPS:

  1. WEBCON BPS processes that server as data sources
  2. External data sources not based on a process

Both of those data sources must contain the same set of elements:

  1. Designation as a personal data dictionary (checkbox)
  2. Unique ID in the source
  3. Personal data source columns

Configuration of the above depends on their type (process/not process), it is different but comes to the same result when used.

 

2.2. Process data sources

Personal data source that is based on a process must contain:

  • WFD_ID identifier
  • Marking the process as personal data dictionary (checkbox)
  • Containing at least one form field in the process definition marked as a ‘Personal data carrier’

 

As a sample process which is a ‘Personal data source’ for the purpose of GDPR, we can set out to create a Contact details process – with the following premise:

  1. One instance in the process means one Contact detail
  2. WFD_ID is a unique identifier of the Contact detail
  3. Process has form fields with following personal data:
    • Name
    • Surname
    • Telephone number
    • E-mail address
  4. Process has GDPR settings configured (marked as ‘Process is a personal data dictionary’) and a defined cleaning mode.

 

Configuration is performed by:

  • Ad. 1 – is a result of the architecture of chosen solution – does not require additional configuration
  • Ad. 2 – is a result of the architecture of chosen solution – does not require additional configuration
  • Ad. 3 – Each of the form fields which is a personal data carrier has to be marked in the Style and behavior tab (Personal data storage section)

    • Data type (Personal data / Sensitive data) is not relevant. What is relevant is designating any of them. Data type has to be ‘Standard’.
    • X-number of form fields can exist on a process, Y-number of which are personal data (X>=Y)
    • ATTENTION!  If the form field/column is configured in the following way:
      • A non-standard data type is chosen (personal/sensitive data)
      • A “Dictionary reference field” OR “Personal data dictionary” is selected
      • Chosen form field with a dictionary OR chosen dictionary
        This kind of field WILL NOT BE TAKEN INTO ACCOUNT as a field in which we search for the provided phrases for the purpose of “Remove personal data” actions (it is one of the SDK actions described in other HowTo article)
        The aforementioned configuration is used to connect instances containing a specific person ID. It is taken into account when conducting actions such as “Remove personal data” (data anonymization) – a topic mentioned thoroughly in the 3. chapter of this article)
  • Ad. 4 –marking the process as ‘Personal data dictionary’

 

A process which is prepared in this way can be used as a data source for other processes, where a connection to a contact person is made. E.g.: a person responsible for the contract, a person taking a part in the recruitment meeting and so on and so forth.

Placing a person’s ID (in this case WFD_ID) correctly is extremely important when searching the database for workflow instances which have ID’s matching to those provided by the administrator.

 

2.3. External data sources

An external ‘Personal data dictionary’ is a data source which:

  1. Is marked as “Data source contains personal data”
  2. Has a designated “Personal data identifier column” in the source (analogously to WFD_ID from process source)

 

Configuration is carried out by going through following steps in the “Data sources” tab:

  1. In the configuration of the specific data source (i.e. MSSQL) please take into consideration sections marked with red frame
  2. Source needs to have “Data source contains personal data” checkbox marked
  3. The source needs to have a column in the data source which will serve as an identifier for BPS:
    • In order to load list of available columns click on the button marked with blue frame (4) on an illustration below

 

This marks the end of external data sources configuration. In cases where there’s a need to search this kind of data sources in order to find an ID (i.e. in ERP) you need to configure an SDK action which searches the data sources, and also map fields in the action configuration (below is a screenshot with an example taken from a different article).

 


 

3.Designating processes to operate through GDPR supporting mechanisms

3.1. Description

Supplementary to the previous chapters here you will see a practical example of process configuration. The main goal is for actions modifying the database content (personal data) to correctly find the searched phrases.

Data is made available to be linked with a personal identifier (from a dictionary) in the following way:

  • At least one form field/column on the Item list is marked as containing personal/sensitive data
  • Choosing a “Personal data dictionary” which holds a user’s ID from the data source
  • Selecting a cleaning mode

 

3.2. Configuration

In order for the following configuration to make sense we assume that a process using data from a personal data source (in our case Contact persons) exists.

  1. Process which uses personal data has defined form fields where one of them is designated as a dictionary form field – configured in such a way to load values from a ‘Personal data dictionary’
  2. On ‘Contact person’ form field use a standard “Target field” function available in picker configuration and automatically set other form fields (name, surname etc.) by placing a value in that field. The result is the storage of personal data loaded from a ‘Personal data dictionary’ in other workflow instances of other processes. It means that data can be propagated in many sections of the system from one original ‘Personal data dictionary’ – and this origin can be easily traced.
  3. The next step is marking form fields on a process which will contain personal data. In this example we will use following fields:
    • Contact person – picker
    • Name – text field
    • Surname – text field
    • Telephone – text field
    • E-mail – text field

 

Configure the process as following:

  • Contact person
    • For data type choose personal/sensitive data
    • Important – select the ‘Personal data dictionary’ (contact person) from which we will obtain data. We can choose from processes in WEBCON BPS marked as ‘Personal data dictionary’ or data sources configured to carry personal data
    • Cleaning mode is defined in the ‘Personal data dictionary’ configuration by default. However it can be overwritten for each form field individually
  • Fields which are not dictionaries e.g. text fields:
    • Set them as personal/sensitive data carrier
    • In the “Dictionary reference field” point to previously configured picker (Contact person) – it means that we’re pointing to a dictionary field from which the configured form field will obtain its data. The system will then be able to track from where each form field obtained its data
    • In case of the basic fields it is impossible to overwrite the cleaning mode. It is defined by the configuration of the form field from which this current form field obtains its data
  • Repeat the above steps for each field which contains personal data

 


 

4. Report generation

4.1. Description

Completing the steps mentioned above for each configured processes will result in a report that summarizes:

  • ‘Personal data dictionaries’ present in the database
  • Processes utilizing personal data with a breakdown of all fields that contain personal data

4.2. Report generation

In order to generate a report go to the WEBCON Designer Studio ribbon .

On the ribbon in the “Tasks” tab select ‘Personal data report’ button. The pop-up window is analogous to the feature for generating process documentation. Select a template, language, and save path.

Below you can see a fragment of a generated report.


 

5. Summary

This configuration example shows us how to begin adapting our business processes to GDPR requirements. Defining, organizing and standardizing data sources and defining connections and placement of personal data storage is definitely a challenge. However it is also a great opportunity to optimize your processes, because understanding how data (especially personal data) is propagated around your system will allow you to limit the usage of sensitive data to only the most necessary places. The key aspect of configuring WEBCON BPS processes to comply with GDPR is to create unequivocal connections between a source of personal data and all fields which load their values from it. This is crucial from the perspective of actions which modify personal data in the system.


 

Leave a Reply

Your email address will not be published. Required fields are marked *