Supplemental Data Management
This topic guides you through the supplemental data management process for deleting customer profile data from supplemental tables. It consists of the following sections:
Overview
To facilitate the 'right to be forgotten' efforts as mandated by laws such as the European Union's General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA) as it relates to the personal data stored by companies, Responsys supports daily asynchronous batch customer profile record deletion. Many Responsys accounts store their customers' personal information in supplemental tables. Supplemental tables are not tied to customer profile records, so customer-specific information stored in supplemental tables is not deleted by default as part of the daily batch customer profile deletion process.
To help you keep your organization's data up-to-date, Responsys provides a method for mapping supplement data tables to customer profiles in a table you can modify, GDPR_SUP_DEL_MAPPING. By mapping customer data, such as Customer ID in an Orders supplemental table, to a corresponding field in the List (profile) table, those supplemental Orders data records can then be deleted as part of the daily batch customer profile deletion process. Similarly, the Orders supplemental data table may be mapped as a parent to a child OrderLines supplemental data table by a common OrderID value.
Important: Only supplemental data table records that have been mapped to a parent table and that mapping has been validated will be removed as part of the daily customer profile deletion process. Any customer records stored in supplemental data tables that have not been joined or linked to customer profile tables (first-level child) or joined to a supplemental data table that is linked to a customer profile table (second-level child) will still have to be manually deleted.
Roles
Important: The actions described herein are to be performed by a Data Director, Super User or Account Administrator.
Only those user levels can access the Data Settings — Supplemental Data Management menu. Therefore, only those users can enable the supplemental data mapping to be used as part of the daily asynchronous customer profile batch deletion process.
Map supplemental data tables to customer profiles
Responsys pre-created the GDPR_SUP_DEL_MAPPING table for you to use to map supplement data table fields to parent customer profiles. The mapping supplies the necessary information to effectively tie fields from supplemental data tables to parent tables so that relationship can be used as part of the daily customer profile cascade deletion process. The table is originally provided as an empty table. Subsequent records you provide define the mapping. You can continue to modify the mapping to meet your on-going needs.
Responsys provides a variety of ways to modify the mapping.
-
Download the GDPR_SUP_DEL_MAPPING table as a CSV file and edit it locally, then upload your changes to the table.
-
Edit the table through the Responsys administrative interface provided.
-
Modify the table using Connect.
-
Revise the table via the APIs.
The first two items above are explained in the following sections. General overview links are provided for the other two.
The general format for the mapping table is shown below.
|
Column |
Data Type |
Populated by |
Required Customer Entry |
Description |
|---|---|---|---|---|
|
PARENT_TABLE_METADATA_NAME |
Text Field (to 255 chars) |
Customer |
Yes |
Name of the Supplemental Data table's parent table (for example, CONTACTS_LIST). If a data subject's record is removed from the parent, the Supplemental Data delete process will look here for mapping related to the named parent table. Parent tables can be profile lists, profile extension tables (PETs), app channel lists, web push lists, and other supplemental tables. The table name must exactly match the actual table's name, including case (upper / lower) and special characters. |
|
PARENT_TABLE_METADATA_TABLE |
Text Field (to 50 chars) |
Validation Process |
No Leave this blank or AS IS |
INTERNAL ONLY Internal DB table name |
|
PARENT_METADATA_TYPE |
Single character field |
Validation Process |
No Leave this blank or AS IS |
Based on internal metadata C = App Channel List S = Supplemental Data table L = Web Push List P = Profile table |
|
PARENT_JOIN_COLUMN_1 |
Text Field (to 50 chars) |
Customer |
Yes |
Name of the column in the parent table that the system uses first to "match" row(s) in the Supplemental Data table. |
|
PARENT_JOIN_COLUMN_2 |
Text Field (to 50 chars) |
Customer |
Yes, if needed |
Name of the column in the parent table the system uses second to "match" row(s) in the Supplemental Data table. Note: Specifying a COLUMN_2 name signifies a composite match condition exists, and this parent record's columns' values must match the Supplemental Data table's record(s) exactly for both columns in the parent and the Supplemental Data table (child table). |
|
CHILD_TABLE_METADATA_NAME |
Text Field (to 255 chars) |
Customer |
Yes |
The name of the Supplemental Data table to clean, based on data removal from the parent table. The table name must exactly match the actual table's name, including case (upper/lower) and special characters. |
|
CHILD_TABLE_METADATA_TABLE |
Text Field (to 50 chars) |
Validation Process |
No Leave this blank or AS IS |
INTERNAL ONLY Internal DB table name |
|
CHILD_METADATA_TYPE |
Single character field |
Validation Process |
No Leave this blank or AS IS |
Based on internal metadata C = App Channel List S = Supplemental Data table L = Web Push List P = Profile table |
|
CHILD_JOIN_COLUMN_1 |
Text Field (to 50 chars) |
Customer |
Yes |
Name of the column in the child table (Supplemental Data table) the system uses first to "match" a field in the parent table. Note: The columns in the child and parent may have different names. The values contained in the respective columns must match. |
|
CHILD_JOIN_COLUMN_2 |
Text Field (to 50 chars) |
Customer |
Yes, if needed |
Name of the column in the child table (Supplemental Data table) the system uses second to "match" a field in the parent table. Note:
The columns in the child and parent may have different names. The values contained in the respective columns must match. Specifying a COLUMN_2 name signifies a composite match condition exists, and this child record's columns' values must match the parent table's record exactly for both columns in the parent and the Supplemental Data table (child table). |
|
VALIDATION_STATUS |
Text Field (to 25 chars) |
Validation Process |
No Leave blank or AS IS |
Status indicating if mapping is valid. Success = Valid Fail = Invalid Invalid mappings must be removed to pass validation and to pass validation and process the cascade delete. |
|
VALIDATION_FAILURE_REASON |
Text Field (to 4000 chars*) |
Validation Process |
No |
Reason the mapping is invalid. Examples:
the following table/column validation failed: the following table/column validation failed: |
|
REC_STATUS |
Single character field |
Validation Process |
No |
|
Create or edit the supplemental data mapping to parent tables
To set up mapping of supplemental data to parent tables:
-
Identify all Supplemental Data tables housing personal data. Of these, identify the tables you want to include in the asynchronous daily profile delete process.
Tip: You can use the Fetch All Supplemental Tables API to get all of the supplemental table data structures for your account.
- The table that defines mapping between supplemental data and customer profiles to be used for the customer profile cascade deletion process, GDPR_SUP_DEL_MAPPING, has been supplied by Responsys. The table is originally provided as an empty table. To access it, select
Folders on the side navigation bar. -
Select All Folders from the drop-down list on the left. Then select Supplemental Data from the drop-down list on the right, as illustrated below. The table resides in the ~System folder.
-
Click
next to the supplemental data mapping table, GDPR_SUP_DEL_MAPPING, to view the popup menu of possible actions to perform. 
Important: This menu contains multiple actions that require that you are careful when making a selection. If you inadvertently delete, purge, rename, move or modify the table such that the system can’t use it, contact Oracle Support to restore the last known good copy or to retrieve it from the Recycle Bin. You may also wish to download a backup copy as a CSV file before you start making edits.
-
Modify the table and save your changes.
Because the GDPR_SUP_DEL_MAPPING table is a supplemental table, there are several possible ways to modify it. The methods we recommend (and document below) are:
You can also use one of the other methods for modifying supplemental tables to modify the GDPR_SUP_DEL_MAPPING table. (The links provided below go to other topics that are not specific to modifying the GDPR_SUP_DEL_MAPPING table.)
To view and edit the supplemental mapping table in the Responsys UI:
-
Select View and Edit Data. The page updates listing the contents of the GDPR_SUP_DEL_MAPPING table, as shown.
-
If records are listed and you wish to edit one (for example, a record was not validated), select the record to edit by clicking the checkbox to the left, then click the Edit button at the top of the page. The page updates showing the mapping to edit. If the table displays with no records listed, or if you want to insert a new record into the mapping supplemental data table, click the New Record button at the top of the page. The page updates showing the record with all blank fields, as shown in the following image.
Note: You can also delete selected records, search for a record, or upload a CSV file containing records to append using the buttons at the top of the page.
The image below is how the page appears when adding a new record.
-
Enter or edit the parent-child "join" conditions as a mapping in the table.
For example, enter CONTACTS_LIST as the PARENT_TABLE_METADATA_NAME value and EMAIL_ADDRESS_ as the PARENT_JOIN_COLUMN_1 value.
-
For the child information, provide the same of the supplemental data table holding the given personal data. Also provide the table column holding a value that matches the value in CONTACTS_LIST.EMAIL_ADDRESS_. Enter this column name in the mapping's CHILD_JOIN_COLUMN_1.
Note: Only valid mappings will be processed as part of the daily customer profile batch deletion process. Invalid mappings are ignored, but all records with valid mappings are processed.
-
Repeat the above mapping entry for each Supplemental Data table to clean via the asynchronous profile delete process.
The cascade deletion supports up to two hierarchical levels of supplemental data. For example,
CONTACTS_LIST → ORDERS → ORDER_DETAILS
Where CONTACTS_LIST is the profile list, ORDERS is a supplemental data table, and ORDER_DETAILS is the another supplemental data table.
The cascade delete process also supports profile extension tables as an initial child.
profile_list → profile_extension_table → supplemental_data_table
Note: PETs are not valid children in the mapping record, as PET data are removed via the original personal data cascade delete process. PETs can be valid parent tables in the mapping.
An example of a profile_list → profile_extension_table → supplemental_data_table would be
Customers → Cust_Loyalty_Profile → Loyalty_User_Activity
Where the customer is in the Customers profile list, their one-to-one loyalty profile info is in the Cust_Loyalty_Profile PET, and their one-to-many transactions are in the Loyalty_User_Activity supplemental data table.
Note:Tertiary children are currently not supported in the current schema for GDPR_SUP_DEL_MAPPING, that is, profile_list → profile_extension_table → supplemental_data_table → supplemental_data_table. In fact, the previous example, generically profile_list → profile_extension_table → supplemental_data_table, is redundant and not recommended. A better form is profile_extension_table → supplemental_data_table.
To clarify:
- profile_list → supplemental_data_table → supplemental_data_table is valid. Two mapping records are needed to achieve this.
- profile_list → profile_extension_table → supplemental_data_table is valid. One mapping record is needed to support this.
- profile_list → supplemental_data_table → supplemental_data_table → supplemental_data_table is NOT valid.
- profile_list → profile_extension_table → supplemental_data_table → supplemental_data_table is NOT valid.
-
At any time as you edit the table, you can click Save (at the top of the page) to retain your changes. When you are finished editing the table, click Save and then Done to exit.
To download the table as a CSV file and edit it locally:
-
Select Download from the menu. A download page displays.
-
Select the character set for the file from the drop-down list.
Note: This download interface is limited to files with 5000 records. In the unlikely event that your file exceeds 5000 records, it must be downloaded using Connect.
-
Click the Download button.
-
Edit the file using a text editor or a spreadsheet application that can save the file in CSV format. Refer to the table above for details on the file contents.
-
After making and saving your changes, upload your edited CSV file by clicking the GDPR_SUP_DEL_MAPPING table listing and selecting Upload-Append from the menu.
-
Validate and enable the supplemental data mapping
To validate and enable the supplemental data mapping for the customer profile bulk deletion process:
-
From the side navigation bar, select
Account. (If you do not see the side navigation bar, click the 
icon.) -
Select Data settings, and then select Supplemental Data Management. (Not seeing this choice? Only Data Directors, Super Users and Account Administrators will see this.) The Supplemental Data Management page displays.
-
Select the Validate button to validate the mappings provided in the GDPR_SUP_DEL_MAPPING table. The process requires valid mappings to execute. If the status of any record is invalid, please go to the supplemental data mapping table, GDPR_SUP_DEL_MAPPING, and fix or delete invalid mappings. Each mapping's status is noted in the table. Invalid mappings are ignored when the asynchronous daily customer profile deletion batch process runs.
-
If the mappings are valid, enable the supplemental data deletion process by selecting the Enabled/Disabled slider. Make sure it says Enabled.
-
Please completely read the consent agreement. If you agree to the consent agreement, place a check in the "I understand the agreement" checkbox, which can only be selected after you have scrolled to the end of the agreement.
Important:At least once per day the asynchronous customer profile cascade delete process removes any records that could be successfully mapped. If a child record could not be identified, these child records, or “orphans”, will not be deleted. Supplemental data table records are only removed as part of the cascade process responsible for removing the parent records. If the parent record is removed outside of this process or via a different session of this process, the orphaned child record remains untouched by this cascade delete process.
In each of the following instances, the resulting orphaned child record must be removed manually:
The child mapping is invalid. The parent record is successfully removed, and the child record is not. The mapping is later corrected and validated; however, the subsequent execution will not remove the child record that remained untouched by the previous process execution.
The parent record was removed prior to adding a valid mapping and/or enabling the cascade delete. The child records in the supplemental data table that have no matching parent will remain untouched by this process.
The parent supplemental data table record or parent PET record was manually deleted, leaving an orphaned supplemental data table record.
-
Click the Save button to commit the enabled configuration.
When you enable the asynchronous profile delete process for your account, the process does not run right away. It starts at the next scheduled run time. The process runs at least daily for all enabled accounts.
Upon the next run of the asynchronous profile delete process, the mapped Supplemental Data tables will be scanned for personal data related to the data subjects deleted from the parent tables, and the corresponding records from the child tables will be deleted. Each time the profile delete process runs, it validates the mappings.
