Salesforce GDPR Sprint (Part 4): Putting Permission Management into Action.

Share this article...

In my previous post (Part 3), I outlined the required custom objects, triggers, and components to build a full Salesforce ‘Permission’ Data Model. With this foundation in place, it’s now time to populate your permissions records with the consent for your existing data.

This post will cover:

  • Adding Marketing Rules
  • Bulk Loading Data Permission Records
  • Automatically added Privacy Opt-ins
  • Bulk Loading Data Permission Records
  • Existing Database: When you’re not covered

Did you know..?
But first, did you know that you don’t need to send every person in your Leads and Contacts an email asking for permission. That seems to be the knee-jerk reaction from most companies. The alternative approach is do nothing.

Adding Marketing Rules

In Part 3, I walked through in detail how to construct your Communication Rules and Privacy Sources using a couple of simple tables. I recommend you refresh your memory, unless you have completed tables for your own organisation.

You will end up with privacy permission records that will look 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.

Whilst it looks complicated, 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 the next post.

Permissions need to be expired automatically when expiry dates are hit. Your CRM needs to automatically unsubscribe all the related opt-ins when a customer unsubscribes. The data model accounts for all of these manual and automated modifications.

So, it looks really simple to the end user because all the complexity has been hidden. And the structure of the rules should be easy to manage by the marketing team because there is no coding as all the data is held in Salesforce objects.

Automatically added Privacy Opt-ins

When a privacy permission record is added, an opt-in record is automatically added for each communication type. The diagram below shows what I mean and what it looks like for a Contact record.

Bulk Loading Data Permission Records

As I mentioned in the opening, you do not necessarily need to go back and contact every Lead/Contact in your database. Under GDPR there are 6 different reasons, called “lawful basis” (covered Part 2), why you can process a person’s data and communicate with them. You need to check with your legal team how you are going to interpret the lawful basis for you different privacy sources.

  • 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.
    • Contracts: for those customers with active contracts where the expiry date is the end of their contract.  Lawful basis is “contract”.
    • 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?)  Lawful basis is “legitimate interest”

Subscribed to newsletter/blog: for subscribers where subscribe date is within y months, where y is your policy (y=6 months?)  Lawful basis is “consent”

The good news is you don’t have to set up every Privacy Permission individually.  A number of Privacy Permissions can be created via data imports based on your existing permissions and consents.

Start with the individuals with the most solid privacy permissions, then work back chronologically based on the last time you talked to a person. Add Privacy Permission records for the following situations, with situation being a Privacy Source:

  • The easiest way is to run a Salesforce report and export to XLS. Add the additional Privacy Permission fields to the XLS and use this to import the data into the Privacy Permission record. Remember, when a Privacy Permission is added, the Privacy Opt-ins are automatically created.
  • Existing Database: When you’re not covered

This section will cover what to do when contacts in your database are not covered by any of the 6 Legal Basis. For every other Lead and Contact you need to go back to the person and re-engage 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 greater the storage costs, the longer it takes to run reports and backups, and the more difficult it is to drive segmented campaigns.

  • “It’s better to have proper engagement with 20,000 customers than to spam 2 million”


Most of you probably viewed GDPR as a huge task where you need to email every person on your database and potentially delete most of them or get fined.

Using the approach we have suggested you can make real progress between now and May 25 and show you have a plan. That is important if the auditors come knocking. It is critically important when customers start asking you about your GDPR readiness.

Remember May 25 is a milestone. What we’ve laid out is going to be necessary long into the future.

GDPR is a change in lifestyle, not a crash diet.


Add Comment