Salesforce GDPR Sprint (Part 3): Start Tackling Consents and Permissions

 

The EU Data Privacy legislation, known as GDPR, is forcing companies that are processing EU resident data to revisit their customer data management with a “Privacy by Design” approach, which will mean re-engineering your Salesforce org and marketing processes to accommodate the GDPR expectations.

Digging into the detail of the 99 GDPR Articles (legal clauses) there are some specific requirements for managing data permissions that will be new to Salesforce customers, and therefore will require customizations to your Salesforce Org.

Previously in part 2, I spoke about the 6 Data Access Requests, specifically how you should extend your Salesforce org to handle these unpredictable and potentially disruptive requests. Now, I will move on building in Consents and Permissions, a new framework for your org that will come indispensable when actioning Data Access Requests.

This post will cover:

  • GDPR Recap: Legal Basis and Data Permissions
  • Building your Marketing Rules
  • Introducing the ‘Permissions’ and ‘Opt-in Consent’ Custom Objects
  • Building the full Salesforce ‘Permission’ Data Model
  • Why it works

GDPR Recap: Legal Basis and Data Permissions

Processed in GDPR is a wide-ranging term – most importantly, what are the valid reasons that we can store and communicate with the person. Under Article 6 of GDPR, data can only be processed for one of six reasons:

  • Consent
  • Contract
  • Legal Obligation
  • Vital Interests
  • Public Task
  • Legitimate Interest

Articles 5 & 7 require you to have evidence of valid data privacy permissions for a specific type of communication and that it has an expiry date.

Building your Marketing Rules

You need default marketing rules first in order to control how Privacy Permission records are added. This will encompass the policies your organisation has for data processing that are outlined by your privacy policies and other documentation – or that remain undecided.

The magic in this approach is end users enter very little data about a privacy permission and most of the information is added according to marketing rules. It may seem a complex as you read down, but it is straightforward when taken step-by-step.

First, Communication Rules.

A Communication Rule is a combination of content and channel. Think about how you communicate with your customers – the marketing campaigns you run and the content you provide.

Below is an example list of content:

  • Product Updates
  • Webinars
  • User Events / Conferences
  • News & Press Releases
  • Blog posts

These are the channels you use to communicate with customers:

  • Email
  • Fax
  • Post
  • Phone
  • Social media
  • SMS

Use a table like the one below, where Content (row) and Channel (column) is matched up, and every tick is a Communication Rule:

Communication Rules are often be driven by the contact information you have for each combination of content and channel, eg. if a customer subscribes to a newsletter and the subscription form only collects email, then there is only one possible Communication Rule: newsletter by email.

Next, address Privacy Source.

Privacy Sources are the ways that the permission could be obtained. Thinking through your marketing and sales processes end-to-end will allow you to identify all the Privacy Sources possible, e.g. contract signed, engaged in sales cycle.

Each Privacy Source needs a defined:

  • Legal basis (listed in the opening section)
  • Marketing period (used to calculate the expiry date)
  • Data retention period

Then, assign Communication Rules to Privacy Sources

Use a table like the one below, where the Communication Rules (columns*) and Privacy Source (row) are matched up, each tick is a Privacy Permission:
*tip: each of these were ticks in the previous table.

The end goal is to have to be able to store privacy permission records that will be something like this:

Met Peter James at Moscone West exhibition stand at DF17 on 7 Nov 2017. Consent was given to send product updates by email and webinar invites by email and SMS. The permission expires on 7 May 2018

All the end user added was Met Peter James at Moscone West exhibition stand at DF17 on 7 Nov 2017.   Send product updates by email and webinar invites by email and SMS came from the table above.  The expiry date was calculated from the marketing period.

Introducing the ‘Permissions’ and ‘Opt-in Consent’ Custom Objects

What is required to track Permissions/Consents

As you can have many permissions for any Lead, Contact or Person Account, you can see it is not realistic to simply add extra fields to these objects to track the permissions.

Instead, you need separate custom objects to hold the permissions.

The picture below will make it easier to understand the Permissions custom object. This is what it could look like for a Contact record.

Disclaimer: this is a screenshot taken from the Elements.cloud Data Privacy Managed Package, but can be replicated in your own org.

The right panel shows the list of permission records – you can see clearly that one of the permissions has expired. The left panel has a new ‘Data Privacy’ tab, which aggregates the information from all the permission records. This gives a comprehensive view of the allowed communications, and which permissions were given to allow them. It also enables users to unsubscribe this customer from the different communications.

An additional object, ‘Opt-in Consent’ has been added. Each privacy permission could generate one or more opt-ins, based on the assigned Communication Rules (e.g. product updates by email  & webinar invites by SMS) for a Privacy Source (e.g. signed contract). Therefore, the opt-in object is required to make unsubscribes and expiry work effectively – for instance when a person unsubscribes from a Communication Rule (e.g. product updates by email)  you need to unsubscribe all of them.  

In the image above and diagram below you can see that there is an opt-in for ‘product updates by email’ that was generated from 2 different privacy permissions – Contract signed and website subscription.

Below is the data structure:  

Building the full Salesforce ‘Permission’ Data Model

Having focussed on the Permissions ‘end product’, that is, how it will look from the individual’s contact record view, this is just one layer of your new Salesforce Permissions data model. You need a few more custom objects to support the Privacy Permissions and Privacy Opt-in objects.

I suggest that data privacy permissions are supported by 5 new custom objects and a set of Apex Triggers & Lightning components, or Visualforce pages.

The additional objects are set to give greater control over permissions, expiry and retention policies for Administrators. You could simply add one custom object, but that means end users would need to enter a lot of data into fields consistently.

Below is the data model and processes mapped in relation to the custom objects (shown in red):

  • Communication Rule: the 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 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 or withdrawing the permission if added in error.

Summary: Why it works

Whilst it looks complex, the truth is that it’s the minimum that you require to be able to support GDPR compliance without killing your marketing efforts. There may be other ways, but this approach ensures compliance without a lot of end user effort and accurate collected data. It’s best understood by thinking about some marketing and sales scenarios, which I will talk about in part 4.

When put into action, Privacy Permission records can be added manually by users, via imports, from websites, or by 3rd party systems like Pardot. 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 an email request or from an unsubscribe button in an email. The data model accounts for all of these manual and automated modifications.

It looks simple to the end user because all the complexity has been hidden. Placing structure to the rules makes managing and modifying them easy for the marketing team (no coding is involved as all data is held in Salesforce objects).

 

To finish up, this post has given you all you need to build your own Data Privacy model. Elements.cloud provides this capability as a managed package called the Data Privacy Manager app, available from the Appexchange at $3,000 /org/year.

Subscribe To The Monthly Newsletter

No Spam. No Rubbish. Just great content from the Salesforce Industry.

You have Successfully Subscribed!

Add Comment