Applies to version 2017.1.3.x; Author: Bartłomiej Spyrka
SDK configuration for an ‘Administration process’ used to find and manage personal data
This article presents methods of utilizing features available in WEBCON BPS to prepare a process for GDPR-related data management. In this article you will learn:
It is important to note that GDPR introduces changes in personal data protection, but does not impose strict rules that must be adhered to in a specific company. The solution presented in the following article is not an A-Z guide but rather a suggestion. You can base your own configuration on it so that your company complies with GDPR.
The entire workflow is presented in the diagram below. However, this article will not cover the configuration of the entire process. The process should be modeled according to your personal needs.
In this article, we will concentrate on the features dedicated to GDPR, how to configure them, and how they work.
In the next part we will focus on the instance’s journey through the various paths of the workflow:
Actions and plugins
WEBCON BPS provides a dedicated SDK toolkit for GDPR. All the plugins are located in the WebCon.WorkFlow.Extensions.GDPR class.
Action searching through process-type personal databases (based on BPS process)
Action searching through external personal databases (other than BPS process)
Action deleting attachments along with their history
Action saving specified user IDs to a technical field
Custom source – collecting personal data
Custom source – personal data usage
Custom source – external personal data sources usage
Action – Delete personal data
Process in a nutshell
A form with very basic data was created on the first step. Based on this form the user in charge (GDPR administrator) of ticked handling should have enough information to correctly isolate the specified elements. Those elements will become keywords for which a search will be conducted throughout “Personal data dictionaries” (external databases and processes).
1. Register step – preliminary ticket registration.
In the next step, the user in charge of ticket handling should:
2. Personal data search
The space between the keywords matters because the system takes into consideration every inputted word and searches for it separately. For example, if it finds at least one of the aforementioned words it will present a result (finding all the keywords is not necessary)
3. Phrase search results – two instances were found, one matching both keywords and one matching one
As you can see on the screenshot above, all results matching at least one of the keywords “star mike” (capitalization doesn’t matter) were aggregated on the item list (“Select person”). In case of finding more than one match, more records will be presented and will be added to the table.
4. Table with search results
The table consists of the following columns:
Next, the process should be able to store the user IDs chosen by the administrator in a technical field. The selected data will be presented in a table one last time for the administrator to confirm, and then proceed to the anonymization/data removal step.
5. Form view just before anonymization/removal
Choosing any of the predefined paths will trigger the corresponding action.
Anonymization will cause personal data in the dictionary instance (and all instances which obtained data from that dictionary instance) to be obfuscated as shown below (applies only to dictionaries based on BPS process):
6. Anonymization results in an instance that obtained data from a personal data dictionary
In order to be able to save identified records you need to:
In the advanced mode, it is possible to compare the variables found in the ‘column ID’ and ‘Searched data’ configuration fields. This is important when analyzing how the ID’s of fields in which results are saved are transferred – and how information is loaded from the form.
If we want to search external data sources we need to use an action dedicated to that purpose. The difference in the configurations is that when searching an external data source, you must first specify which external data source you wish to search.
If the column was marked as false, but at the same time it was searched by the system – the result will be shown on the Item list
In the next step, the user should specify which records will be further processed.
This is done by selecting a record on the Item list (by ticking a checkbox). From the perspective of WEBCON BPS and for further processing, this will copy the IDs to a technical field, from where these IDs can be used for future actions. To copy IDs we will use one of the available SDK actions.
7. Action which copies IDs of selected instances from the Item list to the technical field
The action works by copying the user IDs (found in _ElementID) from the specified Item list (Select person) from selected rows (Select), grouping them, and copying to a technical field (_SelectedPearson) – together with a ‘;’ separator. If we select many rows, the IDs will be stored as follows: ID1;ID2;ID3; and so on.
On the form we can display reports (Item list – fueled by Custom sources) that present two groups of information:
Presents data that is connected with a specified ID (loaded from the personal data dictionary). The dictionary itself and filters are configured on the level of the Item list form field
Configuration – is done via creating an Item list form field and building a filter. In this filter, we will provide the user ID which is relevant to the request (here is an example with [_SelectedPearson])
8. Configuration of Item list form field (SQL Grid) – Collected data
9. Filter configuration on a Data Source
Presents all occurrences of the user’s ID (WFD_ID) with links to specific instances which also contain mention of the user’s ID
Configuration – is carried out in the same way as in the case of data from the personal data dictionaries. The only difference is the usage of a Custom source (using personal data).
10. Custom source configuration for Item list (SQL Grid) form field presentation
11. Item list presenting occurrences of the user’s ID in various process instances
12. Form view after the user ID (identifier of the user who wishes to be deleted from the system) has been locked in
The final procedure involves an action that anonymizes/removes the specified data from the current content database.
In the [Delete personal data] action configuration, point to User/Users IDs that are to be processed (multiple IDs should be divided by semicolons).
The action can work in two modes (switch between them by using the checkbox in the configuration) – it can affect data from WEBCON BPS processes that are marked personal data dictionaries, or data from external data sources (that have been marked as personal data dictionaries):
Configuration for sources based on the WEBCON BPS process
In the configuration, we need only to specify the technical form field which contains the user IDs (WFD_ID). These IDs will then be located in all processes with at least one dictionary form field marked as sensitive/personal data.
13. This form field is marked as containing personal data, which is loaded from the Employee recruitment process
14. The Employee recruitment process is marked as a Personal data dictionary, thus making it a source of personal data
15. Sample configuration of an action that removes personal data from all process-based ‘Personal data dictionaries’
Configuration of actions that remove personal data from external data sources – not based on WEBCON BPS process
Once the ‘External personal data source’ checkbox is marked, it is possible to specify the data source which serves as the ‘Personal data dictionary’ in two ways:
The cleaning mode that will be used by default is the one set in the ‘personal data dictionary’ configuration (either process or data source). However, a different cleaning mode can be set for each form field individually, this will overwrite the cleaning setting in the dictionary.
As you can see, the configuration of processes, actions, and data sources that handle personal data is not much more complicated than the configuration of regular processes. The whole challenge lies in correctly identifying which processes and data sources serve as Personal data dictionaries, and then marking form fields and Item lists columns that load data from these dictionaries.
By correctly identifying form fields that carry vulnerable data in your system and creating a trail of connections that always lead to a personal data dictionary, we can create an airtight solution. No matter where the personal data is used, we can always trace its origin to an instance of a Personal data dictionary – and removing/anonymizing this instance in the dictionary will also purge its data in every place that it was used. A well-thought-out solution will allow you to quickly and accurately find and manage personal data in your WEBCON BPS system.