Updated: Nov 10
Why should you read this?
Because you are curious to understand how others are meeting CCPA and GDPR data privacy requirements when a lead registers, or is created by other means. And how can you adopt a similar approach? Read on...
GDPR/CCPA related consent may apply more directly to Leads. Why? Because Customers and others may have additional lawful bases (basis).
You probably have a 'Contact us' form on your website or other lead gen forms in Social media etc. You may also have an MQL/SQL process related to this flow, and eventually, that lead ends up in Salesforce.
How do you ensure that Consent for these leads is appropriately created and maintained?
We are a software company and one of the sources we get leads from is the Salesforce AppExchange.
Note: If you are not a Salesforce ISV, the first three steps will be different, but the underlying process remains the same.
When someone clicks the "Get it Now" or "Watch Demo" button, Salesforce invokes the lead registration flow.
The requester is presented with a screen to log in. Notice that there is a consent that is asked about sharing the requester's information with us.
Once the requester logins and continues on, Salesforce automatically creates a lead in our Salesforce Partner Org.
Once a lead is created in Salesforce, the process is similar for most businesses that use Salesforce with a Marketing Technology.
When a prospect contacts us for Product information, we consider that as their consent to communicate with them.
Full disclosure: This article describes the process and how we address it using our product, Cloud Compliance (CC). You can build your own..or contact us to learn more.
Once a lead is created in Salesforce, we have an automation that kicks in and does the following:
An individual record is created by and associated with this Lead (and eventually Contact, if this lead is converted). Here, Cloud Compliance's Batch Apex creates and matches the Individual. It can also be done using custom code.
Next, Consent records are created and associated with the newly created Individual. We have a logic that determines what Consents should be created depending on the lead source.
The consents along with their related Channels and Purposes are shown to internal users using Cloud Compliance's Lightning Component. This is useful from a Sales, Service, Call center perspective.
Salesforce's comprehensive Consent data model allows you to capture data points for robust auditability and posterity.
The opt-out is also shown as a prominent banner that is visible across all child tabs to ensure that we respect the Lead's wishes at all times, and do not accidentally do something that is non-compliant.
Our internal user can also update the Consent based on their interaction with the Lead - such as over the phone or email. Cloud Compliance updates/creates corresponding Consent records on the associated individuals. You can do this with some custom code as well.
Our email membership opt-in/opt-outs are based on Salesforce's consent, and Cloud Compliance updates the opt-in & out status based on the Salesforce Consent records. You can use this approach to automate lead subscribe/unsubscribe as well.
This consent expiration based automation approach can work with any Marketing tool that syncs with Salesforce such as Pardot, Marketing Cloud, Marketo, Eloqua etc.
We have a filter to ensure that we are only sending Marketing emails to opted-in subscribers. When a subscriber consent/preferences are updated - either through self-service (described later) or via directly contacting us, this setup keeps us compliant.
All our Marketing emails include a unique link generated by Cloud Compliance to our Consent Management / Self Service Preference Center. You can build this custom functionality or buy Community user licenses and manage it that way.
The lead/contact can update their consent (opt-in/opt-out) by clicking the self-service link. These updates are directly made in Salesforce and eventually propagate down to the email marketing system. This design ensures that we never send any emails to opt-out leads.
An additional safeguard for more stringent requirements can be a double opt-in, where the Marketing/E-mail system initially sends them an email and asks them to opt-in for us to give them additional information.
We have heard this requirement typically from German and other European customers, but are not personally aware if this is really needed. We do not do it, but regulations are interpreted by every customer's own perspective and their risk appetite.
Salesforce customers can build the functionality for Individual, Consent and Self-service themselves but to do it right is neither easy nor cheap.
The answer to a robust and compliant solution requires an integrated and automated approach that serves your end customers/prospects as well as both Salesforce users and Marketing users well.
We hope this is helpful. Our journey to address this and create an effective solution took us various iterations over the last two years and 16+ releases.
Complying with the data privacy laws is a given. However, lead registration and the first follow-up is also the first interaction of a prospect with your organization.
Want to learn more or discuss your specific GDPR/CCPA use cases with the author? https://calendly.com/plumcloudlabs/
An elegant customer experience that respects your customer and prospect's preferences and provides an easy self-service way to update their preferences, we start on the right footing to build customer trust.