If you have ever changed your dentists or doctors then you may have given the authorization to transfer your medical records between providers. This ability to ask for your information is an example of data portability in action - that is facilitated by wonderful laws such as the HIPAA in the USA.
Data Portability is a common requirement across many Data Privacy laws, notably GDPR and CCPA - to ensure that we can ask for our information from other businesses (that are not covered by HIPAA).
You would think that asking for your data should not require an act of Congress (and EU), but it did...and that is how Data Privacy rolls these days ;-)
The intent is to ensure that companies that have your data cannot hold you (or your data in this case), hostage. Therefore, the law provides you the right to ask for your data in a commonly available portable format such as PDF, CSV, etc. In summary, you own your data and have the right to ask for a copy of it!
The definition of personal data has been expanded, it can include your IP addresses, purchase history, photos, appointment details, etc. It is based on the nature and nuances of your business, and how your legal team interprets a reasonable definition of personal data.
If an Individual (aka data subject) makes a Data Portability request (also referred to as 'Data Subject Access Request' or DSAR in the GDPR parlance) for their data, then the law stipulates a fixed number of days for this request to be addressed. Typically, this is 30 days under GDPR for EU residents and 45 days under CCPA for California residents.
Salesforce Orgs are chock full of personal data in Leads, Contacts, Cases, Orders, Marketing Communication, Chatter, Files and Attachments, and whatnot.
As a major CRM system in an Enterprise, Salesforce Orgs is a honeypot of personal data. After all, supporting Sales, Service, Marketing, Customer Support, Collaboration - internal and via Communities, as well as integration with e-Commerce, ERPs, and back-office systems, requires knowing who the customer is.
Extracting records in a portable format from your Salesforce org can be easy or difficult, based on the nature of your implementation. At a high level, the fundamental operation has 3 steps:
Step 1: Identify Objects and fields that contain personal data
The first step is to identify what data do we need to extract. Usually, the legal team at an organization would define what information should be provided for such a request. There may also be a process around identify verification to validate if the requestor is indeed the data subject themself.
If your company has not started compiling a Personal Data Inventory, then this may be a first good step to do so.
A Data Inventory can be handy for this step as it enforces standardization around the identification of personal data in your Salesforce Org. Some forward-looking companies have invested in building a data inventory. Customers typically engage their legal team to identify and map these objects - as part of their Data Inventory and Classification.
A parent-child-grandchild object/field relationship-based mapping is usually needed to fully identify all personal data. AppExchange packages such as Cloud Compliance make this process simpler and robust by using a 'Metadata based Mapping' approach that utilizes a standard, pre-approved mapping to identify data for extraction in step 2.
Step 2: Extract personal data from various objects/fields as marked
This next step is really where the 'rubber meets the road'. Now that we know what data to extract, we have to actually extract it. Customers typically look at three main options:
Manual data extract using reports, SOQL and Data loader type tools
Home-grown programmatic solutions using Apex/Batch Jobs etc.
AppExchange packages such as Cloud Compliance and others
Manual may be a 'good enough' approach for smaller businesses, especially if the number of requests is low, and an 'as-needed' approach can work. Documenting such a process is an important step for this.
Manual data extraction may seem like a simple and low-cost option, but it can quickly run into challenges.
The problems here mostly stem from the manual nature of this option, and include the following:
Lack of consistent processing during Personal data identification
Manual effort-intensive data extraction that can be inefficient
Eventually, a non-standard collation of data (Ref. Step 3) can be error-prone
Home-grown programmatic solutions typically include custom Apex / Batch Jobs, etc. that extract personal data and put it in a custom object, or as an attachment. This can work but tends to add customizations and technical debts, that are often expensive and maintenance prone.
AppExchange packages such as Cloud Compliance make this process less maintenance-prone by taking a more declarative approach. Essentially, the pre-defined mapping (from step 1) is used to extract data using a scalable batch apex approach.
Customers can add robust audit-ability to Portability requests by using Case Object to manage and track data extraction.
Cloud Compliance takes the same architecture approach for DSARs and associates the extracted data records to the DSAR.
Step 3: Collate Personal data and create a PDF, Excel, CSV, etc
The next step is to combine the extracted data and generate a final document - such as PDF, Excel, etc. Some limited transformation may be needed here to expunge any non-personal and company-specific metadata such as field names (that may not make sense to the customer).
Again, the typical three options here are:
Manual collation by copy/pasting in an Excel file or something similar
Home-grown programmatic solutions using Apex/Batch Jobs etc.
AppExchange packages such as Cloud Compliance and others
Salesforce Org is a living system where metadata changes rapidly with new fields/objects. A declarative approach reduces maintenance and increases agility.
These options are similar in their pros and cons with the ones listed for extraction. In essence, frequent changes to the Org can make it expensive to update the extraction and collation mechanism.
Thus, a preferred approach is to build a user interface where a business user or an Administrator can declaratively map the fields that have personal data, and then the extraction and collation mechanisms utilize this mapping.
This insulates the Portability process from changes and ensures that a standardized mapping is used consistently for data extraction and collation. It also automates the process to avoid any manual missteps and assures that we are pulling the correct data all the time, and have a robust audit trail to prove it.
Solving for Portability can be a lot of work, but if you have development and analysis bandwidth, it may be a fun project. Or you may want to consider Cloud Compliance.
In case you do not want to spend time and resources on solving for Data Portability by yourself, then consider Cloud Compliance, the most comprehensive GDPR/CCPA Salesforce App on AppExchange. It is 100% native and 100% declarative.
