In my previous post, I explained current and emerging data protection regulations and the different considerations when designing and implementing a consent management framework. In this post, I explain how Salesforce has set out to address the consent management challenge through a well-considered data storage model and supporting toolset.
Overview
The Road to Consent
Privacy By Design
Consent Driven Engagement
Consent Capture
Consent Event Stream
Consent API
But Wait, There’s More
A Step in the Right Direction
The Road to Consent
Salesforce has been thinking about consent management for some time. Over the past two years, Salesforce has quietly phased-in new storage objects that have come together to form a comprehensive canonical data model to manage all different aspects of an individual’s consent.
Salesforce Consent Management Release Timeline
These ‘Consent Management’ objects are available across all Salesforce editions and provide a highly normalized data structure that accommodate the many different aspects of privacy and consent of an individual, while also enabling organizations to align with current and emerging regulatory environments.
Salesforce Consent Management Object Relationships
Probably the most significant aspect of these objects is that, unlike other standard Salesforce objects, they don’t count towards storage. This is a highly unusual and somewhat radical direction for Salesforce, as their licensing model has always been based, in part, on storage, where an individual record accounts for 1-8KB of storage resources, depending on object type. Perhaps this is a nod from Salesforce acknowledging the impact of managing consent on their platform. By design, a lot of records need to be created to represent an individual’s consent.
“Probably the most significant aspect of these objects is that, unlike other standard Salesforce objects, they don’t count towards storage.”
Privacy by Design
These Consent Management objects have been designed with privacy in mind. The object model closely aligns to privacy by design principles. Specifically, at a holistic level, it provides a proactive data model. Rather than waiting for privacy risks to occur, it prevents them from occurring in the first place, through an organized and standardized set of objects that align tightly to the properties of real-world entities.
Additionally, the data model provides an architectural pattern for organizations to embed privacy into the design and architecture of their IT systems and business processes, rather than bolted-on as an afterthought. As a result, privacy becomes an integral component of the data model without diminishing functionality.
“…the data model provides an architectural pattern for organizations to embed privacy into the design and architecture of their IT systems and business processes.”
Consent Driven Engagement
The Salesforce Consent Management object model broadly classifies consent across four different levels, which can be summarized as:
- Who provided consent
- Which channels they consented to being contacted on
- Via which channel address, and
- What type of content they consented to
Each of these different levels use related Consent Management objects to manage and store consent-related data.
Level 1 Consent
This initial level establishes who the person is and determines what they have consented to at the broadest level. It stores this consent data in the Individual object, where an individual can either be a Lead, Contact, User, Person Account record, or any permutation of these object types (or none of them). The intent of the Individual object is to abstract privacy data from the Lead, Contact, User, Person Account at a record level, and specifically capture the privacy “don’ts” for an individual which include:
- Don’t process: do not process personal data, including collecting, storing and sharing personal data.
- Don’t solicit: do not solicit products and services
- Don’t profile: do not process data for predicting personal attributes, such as interests, behavior and location.
- Don’t track: do not track website session activity and email engagement, such as email opens and clicks.
Additionally, the Individual object also provides individuals the ability to exercise their right to be forgotten through a ‘Forget this Individual’ field and their right to access their personal data through an ‘Export Individual’s Data’ field.
Level 2 Consent
This next level determines which channels the customer wants to be contacted through. The Contact Point Type Consent object defines the named channels (for example, phone or email), and the related opt-in status of an individual for each corresponding channel. An entity relationship exists between this object and the Contact Point Email and Contact Point Phone objects, which both define what time and in which timezone an individual prefers to be contacted. Additionally, the Contact Point Type Consent object always references the Data Use Purpose object (the reason for contacting an individual) and the Data Use Legal Basis object (the legal basis for contacting an individual).
Level 3 Consent
This third level identifies the specific address (or addresses) that the individual wants to be contacted on. The Contact Point Address object is used to store different addresses for an individual. For example, an individual may have both an office address and a home mailing address. The Contact Point Consent object represents an individual’s consent to be contacted via a specific contact point, such as, an email address or phone number. And similar to the Contact Point Type Consent object, Contact Point Consent is also tied to the Data Use Purpose and Data Use Legal Basis objects.
Level 4 Consent
This final level defines what type of content the individual consents to and by which channel. The Communication Subscription object defines the different communication types (for example, newsletter or announcements), which has a relationship to the Communication Subscription Consent object that tracks an individual’s consent against their subscription. Additionally, the Communication Subscription Channel Type object defines the engagement channel used to contact the individual for each subscription. Like levels 2 and 3, it is also tied to the Data Use Purpose and Data Use Legal Basis objects.
Consent Capture
While Salesforce Consent Management objects provide a comprehensive data model for managing an individual’s consent, they’re still just objects. Organizations need to build processes that implement consent capture processes and utilize these objects. While this can seem a daunting task, Salesforce has released a Flow Template that creates and manages Contact Point Type consent records.
“While Salesforce Consent Management objects provide a comprehensive data model for managing an individual’s consent, they’re still just objects.”
Consent Capture from Salesforce Labs
This free Consent Capture Flow Template from Salesforce Labs is available on AppExchange. It consists of Flow Template and a set of Lightning Web Components that guide Salesforce users through the process of capturing consent for an individual, through an intuitive wizard-based interface. Furthermore, the source code is publicly available on GitHub, which provides a good baseline for customization and rapid development.
Consent Event Stream
And consent management in Salesforce is moving beyond the object-level. A Consent Event Stream is currently in pilot. This feature uses Change Data Capture on all Consent Management objects, enabling external systems to subscribe to streaming events when changes occur on a Consent Management object. This event stream aggregates all notifications from objects into a single event stream and provides real-time dissemination of consent data to external platforms, so organizations can be aware when a consent event occurs and could trigger a process, for example, purging customer data when an individual exercises their right to be forgotten.
Consent API
While Salesforce already offers a comprehensive SOAP and REST based API for interacting with objects, the Salesforce Consent API provides the ability to retrieve consent settings for Lead, Contact, User, Person Account, or Individual object records. This ‘read API’ returns aggregated consent data based on an action (or actions), for example, ‘email’, ‘track’ or ‘shouldForget’. In turn, the Consent API provides a convenient method for aggregating and resolving consent data for an individual, without the need to invoke multiple API calls or traverse across complex object relationships. As a result, digital marketing platforms can leverage this API to determine if an individual has consented to receiving communications, and for what specific purpose.
But Wait, There’s More
While Salesforce Consent Management objects provide a very comprehensive and highly normalized data model, we can expect to see additional objects added to complement this data model in the near future. You’ll need to pay attention to the Salesforce Forward Looking Statement, but specifically, a Party Role object will enable the relationship type of an individual to be determined. For example, a customer versus an employee, or a patient versus a doctor. Additionally, you can also expect to see a new Internal Business Unit object which is designed for organizations with multiple brands (for example, a retail group). This object will allow an individual’s consent to be related to one or more specific brands within an organization.
“…we can expect to see additional objects added to complement this data model in the near future.”
A Step in the Right Direction
These objects and their supporting toolset arguably provide the best framework for implementing consent management than any other vendor. But, it’s not a silver bullet. Organizations still need to establish processes to orchestrate consent data collection across different platforms, enable identity resolution, and also build extract, transform and load (ETL) data processes to ensure all related privacy artefacts are captured and stored correctly.
While Salesforce’s approach to consent management is based on a solid foundation, there’s clearly more work to be done. Salesforce isn’t a single platform; rather, it’s a comprehensive platform suite. And while it’s logical to manage consent data in Sales Cloud, it’s also important to consider how to integrate and apply consent management to other Salesforce platforms, including Commerce Cloud, Marketing Cloud and Pardot.
For example, Marketing Cloud already offers privacy and data governance features through a comprehensive subscriber management and contact deletion framework, but it does so independently of Sales Cloud. Extending the Consent Management object model to Marketing Cloud makes a lot of sense. However, considering that Sales Cloud and Marketing Cloud are actually two very different platforms with different data models, considerable effort is required to integrate both platforms. But, if anyone can figure out how to make it work, Salesforce can.
Complying with current data privacy regulations, while also providing agility to adapt to emerging ones is no mean feat. Salesforce has executed consent management through an extraordinarily well-considered canonical model that is both adaptable and maintains a high degree of consistency, which is incredibly important in privacy.
Have questions about how you can implement a consent management framework for your organization? Sign up for our newsletter! We send out a monthly recap of our latest Salesforce Marketing Cloud content, including articles on consent and preference management best practices, actionable insight on Marketing Cloud optimization for enterprises, and more.
