GDPR compliance and Salesforce Individual object
The aim of this article is to make sense of the requirements for GDPR, look at the Individual object and help Salesforce Admins factor it into their implementation plans for GDPR.
If you want to get into the detail of how to ACTUALLY get your Salesforce Org to start being GDPR compliant, then there is a more detailed “nuts & bolts” article here. It covers all the information below, but then dives deeper.
Disclaimer: This is my interpretation based on my knowledge of the requirements of GDPR and of the Individual object’s potential. It is not statement of Salesforce product strategy.
Summary
The Individual object alone will not satisfy the GDPR requirements. You can satisfy GDPR without implementing the Individual object, but you will need to implement some custom objects and write some code.
Individual object
GDPR is forcing companies to revisit their customer data management and data privacy with a “Privacy by Design” approach. Are the heart of this is getting consent from customers to be able hold their data. Article 6 of GDPR says data can only be processed under any one of six reasons; Consent, Contract, Legal obligation, Vital interests, Public task & Legitimate interests See ICO website for definitions
Spring ’18 Salesforce Release added a new standard object: Individual. The individual object is accessed via a lookup relationship to the Lead, Contact, Person Account and custom objects (i.e. Supplier, Partner, Donor). You can also link to the User object via Apex That means an individual who has one or more Lead, Contact, Person Account and custom records could have them all relate to ONE Individual record. This is the primary benefit of the Individual object.
Then the Individual object can hold higher level consent data. Longer term, Salesforce are planning to provide Consent objects that will control the type of consent, when it was obtained and expiry date. This is required by GDPR. There will be processing logic to control the relationships: for example, if “Don’t market” is switched on at the Individual level, it will override any of the more detailed Consents. But until these Consent objects are available you will need to create these as custom objects — or use an app from the Appexchange (Data Privacy Manager or Datapro.tools).
The Individual object needs to be enabled in your Org. Once it is enabled you will need to add an Individual record and connect it to a Lead, Contact, Person Account or custom object. This is done manually, with Apex or Process Builder.
There is some integration with other Salesforce apps/clouds and more are planned in the future. Currently, the Email Opt Out checkbox controls on the Contact object provide access to contact data from Marketing Cloud and Pardot. But this is NOT sufficient for full GDPR compliance. Future functionality may be driven from the Individual and maybe even Commerce Cloud, etc.
You can add custom fields, report and it is Shield Ready. However, it does not have Record Types, there is no auto-numbering on custom fields, and no merge or dedupe until at least Summer18.
The Individual object could be part of the solution for GDPR compliance, but it is currently not the complete solution and the migration issues are not trivial.
What is required to satisfy GDPR?
As we said, the Individual object is not enough on its own to support GDPR, and may not even be required. You need to think carefully about what approach works best for your business as it will have long term implications. For most companies GDPR is a major disruption to how your market, sales and support teams are able to operate. Fundamentally, the source of all privacy permissions is Salesforce, NOT marketing automation. So the marketing lists are driven from Salesforce, not the other way around.
First let’s look at the data model that needs to be in place to be support the processes required for GDPR compliance. In blue are the standard Salesforce objects and the custom objects are in red.
It may look complicated but GDPR Articles 15–22 allow a person to make any one of 6 Request types and Article19 says you have 30 days to respond. This is tracked by the GDPR REQUEST and REQUEST TYPE objects. You could implement this using the standard Case object, but then certain users may not be able to see the records based on their licensing. All users need to be able to see the records.
GDPR Article 5, 6 & 7 require you to be able to show that you have valid consent for a specific type of communication and that it has an expiry date. This is supported by a set of custom objects; PRIVACY SOURCE, COMMUNICATION RULE, PRIVACY PERMISSION, PRIVACY OPTIN, PRIVACY PERMISSION CHANGE. This may seem overly complex, but this is what is required to make it easy for the end users to have the flexibility to support customers, but provide regulatory compliance. You could simply add one custom object but that means end users would need to enter a lot of data into fields consistently.
Custom Object definitions:
GDPR REQUEST: Type and date/time stamp for request
REQUEST TYPE: Policies for each of the 6 GDPR request types
PRIVACY SOURCE: How did you obtain the opt-in: Product/service contract, Website subscription, Met at event, inbound inquiry… Default expiry period for that source: 1 year, 3 months
COMMUNICATION RULE: The communications allowed for each opt-in source: Product Update via email, Product update via SMS, Event invite via email
PRIVACY PERMISSION: This is evidence of the specific permission and expiry date: Met at DF17 on 7 Nov 2017
PRIVACY OPTIN: The communication allowed based on the Communication Rule associated with the Privacy Source. This is what is unsubscribed.
PRIVACY PERMISSION CHANGE: Extend or withdraw a permission.
You can see that Individual is not directly connected to the consent data. The Individual object links together one person who is recorded in Salesforce in their different roles. The data model shows that a person has a set of consents based on their role. The higher level consents may be captured at the Individual object but there is no logical link to the consent data. The relationship is programmatic i.e. if “do not contact” is checked on the Individual object then it will override all consents.
How you are able to spot that a Contact is the same person as a Lead is clearly challenging to automate and this is discussed a little later in this article.
Implementation strategies
Clearly to comply with GDPR you are going to need to implement some way of tracking requests and consents. You will need to implement the custom objects in the diagram above along with the supporting processes.
But the question is “How does the Individual object fit in my GDPR strategy”. So here are the 3 approaches as we see them:
1. Ignore the Individual object
You already have Contacts and Leads which probably have some custom fields around “subscribe / do not contact”. You need to implement a method to track permissions that is more than just checkboxes, connected to the Contacts and Leads.
PRO
- No huge changes to page layouts reporting and automation when capturing new Contacts, Leads or Person Accounts
- Process Builder is available to automate Contact and Lead objects
- No Individual records to add and no consent data to be transferred off the Contacts and Leads
CON
- You have no aggregated view of consent data if you have one person that has multiple Lead and Contact records
- May need a future implementation project to migrate to the Individual object which is further disruption
2. Contact and Lead are the master records with high level consent data transferred to Individual object
You take all consent data off the Contact, Lead, Person Accounts and custom objects and add it to a custom object attached to the Individual. This means creating an Individual record for Contact, Lead, Person Account and custom object records and migrating the data.
PRO
- You are not duplicating consent data on Contact, Lead, Person Accounts and custom objects where it is the same person
- You can manage Community Users / Contact relationship more easily via the Individual object
- You will be able to take advantage of future Individual object functionality
CON
- Migrating requires Apex or manual effort to create the Individual records for every Contact and Lead
- Changes will be required to operational processes, page layouts, reports when Contact, Lead, Person Accounts and custom objects are created and maintained.
3. Individual object is the master record
This is a more radical approach, but is embracing Privacy by Design. You make the Individual the master record for anyone you keep track of data on, so it is easier to drive a customer centric approach to data privacy. When you get a new Lead or Contact, first you look for an Individual record and then connect it to the new Contact or Lead. This means that you could move to a situation where the customer could manage their own consents and the different “personas” that the deal with you.
You will need to take all personal data off the Contact, Lead, Person Accounts and custom objects and and add it to a custom object attached to the Individual. This means creating an Individual record for existing Contacts, Leads, Person Accounts and custom objects. You will also need more sophisticated processing before you create an Individual record to check if it already exists so that you eliminate duplication.
PRO
- You are putting the customer at the center, and managing data from a person perspective not role
- You will be able to build a self-service customer preference center
- It is easier to remove / anonymize the Individual object that the Lead, Contact, Person Account or custom object
- You will be able to take advantage of future Individual object functionality
CON
- A radical change in the whole CRM approach and changes will be required to operational processes and Salesforce config
- Migrating requires Apex or manual effort to create the Individual records
- The de-duplication approach and creating the Individual record is unproven and has no automated support.
Implementation considerations
Unique identifier:
The power of the Individual object is that it can relate to multiple Contact, Lead, Person Account and custom object records. But we need to be able to confidently identify that a Contact record is the same person as a Lead record on a custom object record. What is the unique identifier — user name, email address, cellphone, social security number?
Automation of de-duplication:
Without a unique identifier how can you automate the creation of one Individual?
Few ISVs have incorporated the Individual object:
ISVs that are managing or enhancing data on the Lead or Contact –their custom objects — have not yet added support for the Individual object. This may prevent you from using the Individual object.
Suggested approach for creating Individual records
Here is more pragmatic approach for creating Individual records. Instead of simply using Apex to create an Individual record connected to every Contact, Lead, Person Account and custom object, we suggest you take a segmented approach, starting with those records where you have the strongest consents.
1. Create an Individual record connected to every Contact that has a contract with you. At the same time add the Privacy Permission record with a Privacy Source of “contract”. This validates that you have a contractual agreement in place to process data at the time that they are a customer.
2. Look at all Contact with open Opportunities. Before you create a new Individual record, check if an existing Individual record exists (using whatever matching you can) and connect it to the Contact. If not then create a new Individual record. Also add the Privacy Permission record with a Privacy Source of “Legitimate Interest”. This validates that they are an engaged customer and can fall into the basis of having a shared legitimate interest in your organization
3. Then look at Contacts that are connected to campaigns. What are those campaigns and how long ago were they? Are you confident that the person actually consented to you holding their data? If you have a record of where/when they would have opted in, this consent may still be valid, but you will need to make sure your legal team are happy with this approach before you make that decision.
4. Which Contacts have not yet been touched? Do you have any history or evidence that the person actually consented to you holding their data?
5. Finally, look at your Lead data. Do you have any history or evidence that the person actually consented to you holding their data?
The final word
Taking a full Privacy by Design approach will reap long term benefits, using the Individual object and adding custom consent objects, but it is not a quick fix for GDPR. For larger organizations it is difficult to see how they can fully comply without taking a Privacy by Design approach.
For brand new implementation, then it makes sense take the “Privacy by Design” approach advocated by the GDPR, and use the Individual object as the basis of privacy data. But effort of creating the Individual record should not be overlooked.
Whatever approach yo take, if you want to be GDPR compliant you need to track permission (consent) data in custom objects.
Fantastic — you’ve read this far. You now need to read this a more detailed “nuts & bolts” document. It explains how to implement GDPR using Salesforce and Salesforce+Pardot.
