GDPR - Administration Process

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:

• How to approach the Administrative process which is used to track down a specified user’s personal data
• Which WEBCON BPS features can be used when designing a process
• How to configure SDK and actions related to GDPR
• How to perform data deletion/anonymization in BPS processes
• How to collect information about stored personal data
• How to obtain information about all personal data usage in the system

 

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.

 

Concept

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:

• Register a request – input basic data
• Personal data search - methods of searching through the database and saving the results on the form
• Select person – specifying which users returned by the search will be processed further
• Remove data – the final step in which the data anonymization/removal is conducted

 

Actions and plugins

WEBCON BPS provides a dedicated SDK toolkit for GDPR. All the plugins are located in the WebCon.WorkFlow.Extensions.GDPR class.

Tools provided:

• 4 SDK actions are used for operating on data sets
• 1 action – anonymization/data removal
• 3 custom data sources are used for providing data to Data Table (SQL Grid) reporting controls

 

Action searching through process-type personal databases (based on BPS process)

• WebCon.WorkFlow.Extensions.GDPR.Actions.FillPersonalDataItemList

Action searching through external personal databases (other than BPS process)

• WebCon.WorkFlow.Extensions.GDPR.Actions.FillPersonalDataItemListCustomData

Action deleting attachments along with their history

• WebCon.WorkFlow.Extensions.GDPR.Actions.RemoveAttachmentWithHistoryAction

Action saving specified user IDs to a technical field

• WebCon.WorkFlow.Extensions.GDPR.Actions.SaveIdsToTechnicalField

Custom source – collecting personal data

• WebCon.WorkFlow.Extensions.GDPR.DataSources.DictionaryDataReportDataSource

Custom source – personal data usage

• WebCon.WorkFlow.Extensions.GDPR.DataSources.ElementsGridDataSource

Custom source – external personal data sources usage

• WebCon.WorkFlow.Extensions.GDPR.DataSources.ExternalElementsGridDataSource

Action – Delete personal data

• This is a normal BPS action, it is available in the standard way (analogous to all other actions)

 

 

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:

• Type in search keywords which will lead to identifying the user who requested data rectification
• Words should be typed in the “Search” field
• Keywords should be divided by a “space” i.e. “John Locke 4815162342”

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:

• Select (checkbox column) – used for selecting the search result(s) that we want to process
• Link – leads to workflow instance (if the search result belongs to the dictionary based on a WEBCON BPS process)
• Field name – displays the Form field names in which the searched values were found (in this case name and surname)
• Value – displays the values which matched the searched keywords
• Dictionary – displays the name of the personal data dictionary in which the specified record was found

 

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

 

Configuration

In order to be able to save identified records you need to:

1. Create a text field for inputting keywords (Input/search)
2. Create an Item list with columns for data
   
   The Item list has a straightforward construction. When searching the data source (which is also a BPS process), it is possible to create a technical column that stores the instance ID (WFD_ID). Then in a different column, create a hyperlink that will take you to the selected workflow instance.
   
    
3. On the transition path, configure an action searching the dictionaries and saving results to the Item list. An example is shown below:
   
    

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.

 

• Name - Column name in the data source
• Searching - Defines if the system should search by a specific column (by phrase)
• Visibility - Specifies if a selected column [name] will be visible on the search result list
  
   

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:

 

Dictionary data 

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

 

Related workflow

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

 

Deleting personal data

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.

Configuration examples:

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:

• Static data source selection (choose from a list)
  
• Dynamic data source selection – choose <Calculable> from the list, and then use a rule or variable that will return the ID of the desired data source {DS.:174}) – this method allows one action to be used on multiple sources and can be looped, for example by using a Flow control (branch) step.
  

 

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.

 

Summary

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.