Implementing GDPR using Salesforce & Pardot
Disclaimer: This is my interpretation based on my knowledge of the requirements of GDPR, Sales Cloud, the Individual object and Pardot. It is not statement of Salesforce product strategy.
THE BOTTOM LINE
GDPR is not impossible to implement, but it is not trivial. It requires a change in culture around customer data management that hits marketing teams hardest, but has implications across the organization. Simply doing the analysis of what areas are impacted will highlight quick wins where the organization can be leaner, drive out waste and be more effective. GDPR can drive better marketing and business development with some small changes to Salesforce and Pardot. Those who implement GDPR will gain massive competitive advantage over those hoping it won’t affect them (hint: it will eventually).
1. Understanding GDPR compliance
The EU Data Privacy legislation — GDPR — is forcing companies that are processing EU resident data to revisit their customer data management and data privacy with a “Privacy by Design” approach. This will require a review of all customer touchpoints; marketing, sales and support. And then reengineering Salesforce processes.
But the heart of the GDPR really comes down to three key areas:
- Security/Data Protection: In other words, preventing unauthorized access to personal data
- Accountability: Being accountable and transparent as an organization on how you manage & protect individuals’ data
- Individual’s Rights: When delivering products and services, companies must ensure they preserve individual’s privacy and give individuals choice over how their data is used
Most companies are, or will be, impacted
There a number of reasons why companies need to rethink their customer data management and comply with GDPR — even if they are i) not going to be able to hit the 25 May 2018 deadline, ii) do not process EU resident data, or iii) a smaller company that is unlikely to be targeted by the GDPR auditors.
Firstly, GDPR legislation will be in place for years to come so 25 May 2018 is just a milestone. Secondly, other countries around the world, the US included, will start introducing similar legislation for data privacy. Finally, large companies who are complying with GDPR will require that their suppliers are GDPR compliant. Those suppliers will turn around to their suppliers and require GDPR compliance from them: trickle down GDPR
Benefits not fines
Compliance is not all cost. Done right there can be a positive ROI. These benefits can be grouped into 3 areas:
- Reputation; GDPR compliance is a clear demonstration of the highest level of customer data privacy and can be used a competitive advantage at a time where consumers are very aware of how widespread their data is being misused
- Improved customer engagement; getting customers to validate that they are happy to receive communications means that you can focus on them and build more meaningful relationships, rather than wasting time on “dead’ contacts
- Process optimization; up to 25% of waste can be eliminated by getting a clear understanding of the operational marketing and sales processes so that they can be optimized and repeatable
2. Specific GDPR Salesforce requirements (GDPR Article 5, 6 & 7)
Digging into the detail of the 99 GDPR Articles (legal clauses) there are some specific requirements for managing customer data and data privacy permissions that will be new to Salesforce customers. These will require changes to marketing and sales processes and customizations to the Salesforce Org. There are 2 areas of the GDPR legislation that will mean you will need to extend Salesforce.
The first is widely talked about — “the right to be forgotten” which is covered in this article — and the other area is tracking permissions or consents. This is arguably a more complex and important area as to affects EVERY lead and contact.
This means getting permission (consent) from prospects and customers to be able hold their data and engage with them. Article 6 of GDPR says data can only be processed for any one of six reasons; Consent, Contract, Legal obligation, Vital interests, Public task & Legitimate interests.
GDPR Articles 5 & 7 require you to be able to show evidence that you have valid data privacy permissions for a specific type of communication and that it has an expiry date. These permissions are will need to be added and then expire or are withdrawn when a customer unsubscribes.
Before you all freak out, you do not necessarily need to go back and contact every person in your marketing Prospect List and Salesforce Leads and Contacts. All your existing contracted customers will have permissions based on their Contract. Those prospects where you are engaged in a sales cycle will be considered a Legitimate Interest. Those who have subscribed to blogs and newsletters will have given Consent — provided it is still valid based on the date that they subscribed. You will need to add a permission record for each of these.
For example, here are a set of permission records;
- product updates allowed by email because agreed when attending Dreamforce17 workshop on 8 Nov 2017 and this expired on 7 Feb 2018
- product updates allowed by contract because signed up for service on 5 Jun 2017 and due to expire on 6 Jun 2018
- product updates allowed by email because subscribed on website on 13 Jan 2018 and due to expire on 12 July 2018
- event invitations allowed by email because subscribed on website on 13 Jan 2018 and due to expire on 12 July 2018
- event invitations allowed by SMS because subscribed on website on 13 Jan 2018 and due to expire on 12 July 2018
3. New marketing realities
No longer is marketing in control of which people are on any marketing list. Before GDPR, prospects were an enormous pool of emails to be nurtured. GDPR turns that on its head. Now only those people who have consented to be contacted should be on a marketing list. And those permissions could come from sales operations (contracts), sales (legitimate interest), customer success (support subscription). And, of course marketing (events, inbound subscription, web to lead).
This means that the permissions need to be managed in Salesforce against Leads and Contacts and the permissions then add and remove people from marketing lists in Pardot.
As you can have many permissions for any Lead or Contact you can see it is not realistic to simply add extra fields to these objects to track the permissions. Instead you need a separate custom object to hold the permissions.
Often a picture makes it easier to visualize what is required. This is what it could look like for a Contact record. In the right panel is the list of permission records. You can see that one of the permissions has expired. In the left panel, there is a new data privacy tab which aggregates the information from all the permission records. This gives a view of what are the allowed communications, and which permissions were given to allow them, and also enables you to unsubscribe this customer from the different communications. Clearly you cannot maintain every record manually, which is why you need a tight integration into Pardot.
3. Where does the Individual object fit in?
The Individual object was released in Spring18.
In summary: The Individual object alone will not satisfy the GDPR requirements. You can satisfy GDPR without implementing the Individual object.
The benefit of the Individual object is that it links together any person who is recorded in Salesforce in their different roles. That means a person who has one or more Lead, Contact, Person Account and custom records could have them all relate to ONE Individual record. So, longer term using the Individual object, a person could manage all their permissions through a customer facing preference center. But this requires some of the current limitations of the Individual object to be addressed in future releases;
- 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 for each Lead, Contact, Person Account or custom object. This is done manually or with Apex because Process Builder is not yet supported.
- You can add custom fields but record types or auto-numbering is not supported.
- There are no tools for being able to identify a person that is both in Leads and Contacts and then merge these links to the Individual object.
The inability to easily identify and connect an Individual to multiple Leads and Contacts is the most challenging issue. If this is not resolved, you will simply have one Individual record connected for every Lead and Contact which is a huge overhead with limited benefits.
The Individual object is part of Salesforce’s journey to providing more comprehensive compliance support but to fulfil GDPR it will require data privacy permission objects to be added by Salesforce. Until then, these will need to be added as custom objects connected to the Lead (or Contact) or to the Individual object.
4. The marketing cycle
The opt-in permissions drive the email marketing cycle (shown below). If you remember GDPR means that you can only send marketing to those people who have given consents / opt-ins. These opt-ins need to specific rather than just an overall marketing opt-in. Here are examples of 3 different opt-ins — product updates by email, event invites by email, event invites by SMS.
The opt-ins determine which people are added and removed from the Pardot Lists or your marketing automation solution. The challenge is completing the cycle, as the unsubscribes and resubscribes that are received in Pardot need to be reflected back as updates to the opt-ins in Salesforce.
4. Extending Salesforce for tracking customer permissions and consents
First let’s think about how we track and manage the opt-ins — which we call privacy permissions — in Salesforce. We suggest data privacy permissions are supported by new 7 custom objects and a set of Apex triggers and Lightning components or Visualforce pages. You need a few more custom objects rather than just a Privacy Opt-in object. The additional objects are for the Marketing Administrator to set up so there is greater control over the permissions given and the expiry and retention policies are controlled. You could simply add one custom object but that means end users would need to enter a lot of data into fields consistently.
Records can be added by users manually, by imports, from websites and by 3rd party systems like Pardot (in-bound prospects), event apps (registration, attendance or exhibition lead capture), web to lead (when people subscribe), finance (when a new supplier is added), partner (new partner contracts) and so on.
Permissions need to be expired automatically when expiry dates are hit. Also, you need to be able to automatically unsubscribe all the related opt-ins when a customer unsubscribes through a preference center, by a request or on a mailing.
Elements.cloud provides this capability as a managed package called the Data Privacy Manage app. It provides the Salesforce objects, Apex and reports and the Pardot integration. Get 7 day trial on appexchange. This short video talks through the principles and demos the app.
Or you can read through the rest of this section to understand how to you can build your own Data Privacy app.
The custom object structure is in the data model below. Whilst it looks complex, it is the minimum that you require to be able to support GDPR compliance without a lot of end user effort and whilst ensuring the data collected is accurate. It best understood by thinking about some marketing and sales scenarios, which is in the section after the data model.
Custom object structure
COMMUNICATION RULE: Type of communication and channel: Product update by email, Product update by SMS, News by email, Event invitations by email, Event invitations by SMS, Event invitations by phone…
PRIVACY SOURCE: How did you obtain the permission: Product/service contract, Website subscription, Met at event, Inbound inquiry. It holds the default expiry and retention periods for that source which are set as policies by the company: 1 year, 3 months…. It also links to the different content you can send using the Communication Rules: Product Updates, Event invites…
PRIVACY PERMISSION: This is the record of the permission that was given; Met at DF18 on mm/dd/yy
PRIVACY PERMISSION OPT-IN: This is automatically created for each type of consent that was given as the Privacy Source may allow multiple content to be send. This holds the granular permission that makes it easy to automatically unsubscribe records.
PRIVACY PERMISSION CHANGES: This records any changes such as extensions to permissions
Adding default data to the Data Permission Objects
There is some default data that needs to be added before you can start adding Data Privacy Permission records. This will require you to think through your marketing and sales processes and then agree your channels and some policies on the period of time you are able to continue to contact customers.
Communication Rules
A Communication Rules are a combination of content and channel
This list below is an example list. You need to build your own list. Try to be specific, but keep them to a minimum. This is your chance to review your current content and rationalize it.
Think about the campaigns and mailings you run, the content you provide and the channel:
- Product Updates by email
- Product Updates by post
- Webinars by email
- User Events / Conferences by email
- News & Press Releases by SMS
- Blog posts by email
Privacy Source
Now think about the ways that the permission could be obtained. Privacy Sources e.g. Contract signed, Engaged in sales cycle. You will need to think through your marketing and sales processes to identify all the privacy sources and the allowed communications for each. You also need to add the legal basis, the marketing period and data retention period for each Privacy Source. You can also think about whether the Privacy Permission will be added manually or automatically by a workflow, form or app.
It is best described as a table, to see the Communication Rules (columns) for each Privacy Source (row): (here’s an XLS working sheet for you to use)
Adding Data Permission records
You need to create Privacy Permissions, which are the evidence of the permission, and then the related Privacy Opt-ins are automatically created. The Privacy Opt-ins allow unsubscribes to be managed at the content level. Below is an example.
Privacy Permission: Met at DF17 on 8 Nov 2017 and exchanged business cards.
Based on this Privacy permission and the Communication Rule — exchanged business cards- there are 2 Privacy Opt-ins that are created automatically with expiry dates (based on the table above):
- Product Updates by email until 7 Feb 2018
- Webinars invite by email until 7 Feb 2018
These Privacy Opt-ins mean that you are managing unsubscribes properly. For example, a customer unsubscribes from Product Updates by email. Then ALL the Privacy Opt-ins for Product Updates by email which were created create due to the different permissions that were set up from the multiple interactions (Privacy Sources e.g met at event, exchanged business cards, signed contract) would be unsubscribed. You cannot manage unsubscribes at the permission level.
Bulk loading Data Permissions
Don’t worry. You don’t have to set up every Privacy Permission individually. There are a number of Privacy Permissions that can be created as data imports based on your existing permissions and consents. This is the initial set up and then the ongoing maintenance is covered next.
Start with those that have the most solid privacy permissions and then work back chronologically in time based on the last time you talk to the person. So, you can add Privacy Permission records for the following situations:
- Contracts: for those customers with active contracts you can add a Privacy Permission record and expiry is the contract length
- Open opportunity: for contacts in the sales cycle where opportunity last updated date is within x months where x is your policy (x=6 months?)
- Subscribed to newsletter / blog: for subscribers where subscribe date is within y months, where y is your policy (y=6 months?)
- Leads / contacts: where campaign date is within z months, where z is your policy (z=3 months?)
The easiest way is to run a Lead or Contact report, export to XLS. Then add the additional fields to the XLS and use this to import the data into the Privacy Permission record. When a Privacy Permission is added, the Privacy Opt-ins are automatically created.
Reengaging customers to get consent
For every other Lead and Contact you need to go back to the customer and reengage to get consent. And if you don’t get consent you need to decide what to do. You don’t have to delete them if you want the data to build trend analytics, but you need to make sure that you cannot accidentally start marketing to them. The more “dead data” you have, then the more storage costs, the longer it takes to run reports and backups and the more difficult it is to drive segmented campaigns.
“It is better to have proper engagement with 20,000 customers than spamming 2 million”
5. Integration with Pardot marketing automation
Principles
Salesforce Leads and Contacts control which records are added to Pardot Marketing Lists. Prospects can be added to Pardot but should NOT be added directly to Pardot Lists. The prospect is sync’d with Salesforce and based on privacy permissions it is then automatically added to Pardot Marketing Lists.
Each Communication Rule is mapped to one or more Pardot Marketing Lists. So, when a person is subscribed to a Communication Rule in Salesforce they are automatically added to the mapped Pardot Marketing Lists.
When a person unsubscribes in Salesforce from a Communication Rule then they are automatically removed from the mapped Pardot Marketing Lists. If a person unsubscribes from a Pardot Marketing List then the privacy permissions for the related Communications Rule will be updated in Salesforce.
When a new prospect is created in Pardot from a lead form — which has a consent / subscribe — it will be automatically added to Salesforce and the privacy permissions will also be added. It will not be added to a Marketing List.
Pardot Integration Set up
1. Add custom field “Communication Rules” to the Prospect List and connect to the Salesforce field with the same name. API name = “datapm__CommunicationRules__c”
2. Create 2 automation rules for every Marketing List. One to add, and one to remove prospects to that Marketing List based on code for the Communication Rules that are contained in the “Communication Rules” field.
3. Create a Salesforce Task to communicate from Pardot to Salesforce. An Apex trigger will process the Salesforce Task based on the subject and comment text. The formatting of the Salesforce Tasks is in next section. These are the Salesforce Tasks you may need to set up:
a. Subscribe to a list — set up using a Pardot Automation Rule.
b. Unsubscribe from a list — set up using a Pardot Automation Rule.
c. Add a prospect from a Pardot form (simple) — use Pardot Form completion action.
d. Add a prospect from a Pardot form (dependent on field values) — use Pardot form handlers. Here is the help explaining how to do this https://help.salesforce.com/articleView?id=Using-Form-Field-Based-Completion-Actions&language=en_US&type=1
Salesforce Task formatting
To be able to generate a Salesforce Task that the DPM can process, you need to set them up with specific text in the subject and comment fields. These can be set up by any application — Pardot, event management, web to lead forms, automation, contract management…
Add subscription
The task needs to be set up for a Lead or Contact with:
- Subject text: Datapm:Subscribe
- Comment text: {“psCode”: <psCode>, “description”: <description>}
replace:
<psCode> with Privacy Source 6 digit code
<description> with reason e.g. DF17
Unsubscribe
The task needs to be set up for a Lead or Contact with:
- Subject text: Datapm:Unsubscribe
- Comment text: {“crCode”: <crCode>}
replace:
<crCode> with Communication Rule 6 digit code
Pardot form will create a prospect, which will sync to Salesforce Lead or Contact. When it is matched to a Salesforce Lead or Contact, the Salesforce Task will be created automatically. The task needs:
- Subject text: Datapm:Added
- Comment text: {“psCode”: <psCode>, “description”: <description>, “optin” : Boolean}
replace:
<psCode> with Privacy Source 6 digit code
<description> with reason e.g. DF17
Boolean with true or false
Optout lead/contact
In Pardot if a prospect opts out from all lists then all the active Communcation Rules on the Contact or Lead need to be unsubscribed. The task needs:
- Subject text: Datapm:Optout
- Comment text: {}
6. Privacy permission scenarios
Scenario 1 — new lead or contact captured: at event, exchange business card, website registration form…
There are several ways that the permission could be obtained. This is not an exhaustive list, but gives you an idea of the situations. You will need to think through your marketing and sales processes to identify the different ways you interact with customers (and partners) and then how you would add the Privacy Permission record:
· Contract signed: Process Builder Workflow triggered when the status of Opportunity changes that adds Privacy Permission record to Contact. The Privacy Opt-in records are added automatically.
· 3rd party app generates: An app may need to create a new Privacy Permission record. For example; a workflow forms app collects customer marketing data on a website; a project management app adds a new team member; a student applies for a university course. The Privacy Permission is a custom object, but the app needs to be able to provide the Privacy Source.
· Engaged in sales cycle: Process Builder Workflow triggered when a new Opportunity created that adds Privacy Permission record to Contact. The Privacy Opt-in records are added automatically
· Inbound sales request: depends on sales process… Is added as Lead (or Contact)? Is an Opportunity raised? Is a Contact status changed? Manually add records or Process Builder Workflow triggered when a new Opportunity created / Contact field status changes that adds Privacy Permission record to Contact. The Privacy Opt-in records are added automatically.
· Salesperson exchanges business card: manually adds Lead (or Contact) plus Privacy Permission and then Privacy Opt-in records are added automatically.
· Leads captured at event from business card bowl clearly marked with consent: manually entered adds Lead (or Contact) plus Privacy Permission record or by XLS data import to add Lead/Contact and then 2nd import to add Privacy Permission record. The Privacy Opt-in records are added automatically.
· Leads captured through scanner where consents are checked: by XLS data import to add Lead (or Contact) and then 2nd import to add Privacy Permission record. The Privacy Opt-in records are added automatically.
· Lead capture form on website where consents are given: added to as a prospect in Pardot and a Salesforce task is added to add the Privacy Permission record and the Privacy Opt-in records are added automatically.
Scenario 2 — run email campaign and then customer unsubscribe
Run campaign using a Pardot list. When a person unsubscribes from a list, then Pardot automation will create a Salesforce Task. The Apex trigger in Salesforce executes the task by updating the Privacy Opt-ins. Neat!!
Scenario 3 — customer requests unsubscribe
If a customer calls, emails, writes in, or posts on social media that they want to be unsubscribed from a particular source, then the active Privacy Opt-in records that relate to the Communication Rule and need to be manually unsubscribed in Sales Cloud.
Scenario 4 — using Email Opt-out and Do Not Call fields
The Privacy Opt-in records would provide the same capability but at a more granular level, so these fields do not need to be used. But if they are used, then:
· If you are using the standard field, Email Opt Out, and it is unchecked then the related email Privacy Opt-ins should be set to unsubscribe using Apex, Flow or Process Builder.
· The same for the standard field, Do Not Call, then all phone Privacy Opt-ins should be set to unsubscribe.
Scenario 5 — marketing & sales team reach out to Lead (or Contact)
Marketing or sales person looks at the active Privacy Opt-ins in Sales Cloud to see if they are able to contact the Lead (or Contact) using the Communication Rule. This should be aggregated and presented as a summary on the Lead (or Contact) record, rather than having to read all the Privacy Opt-in records.
Contact
Ian@elements.cloud . @iangotts
Data Privacy managed package on Appexchange . $3000 /Org / year
