Showing posts filed under:

Marketing Cloud

Salesforce International Data Privacy

Data protection and privacy regulations have been a key area of focus for most organisations over recent years. Such regulations are emerging – more so than ever before in 2023 – and non-standard across international boundaries, which for multinational businesses poses a real challenge in respect to compliance and risk. The penalties for non-compliance can be significant in both monetary and reputational terms.

This post provides an overview of data protection and privacy regulations across key Salesforce markets and highlights the key elements to be considered for multinational implementations. Please note that this overview is necessarily indicative in nature given the complexity of the subject area; organisations should always take expert advice in respect to their legal obligations. Further to describing the regulations, a summary is provided of the solution options available on the Salesforce platform natively or via the AppExchange for managing data protection and privacy compliance.

Key definitions:

  • Personal Information (PI) : any information related to an identifiable individual.
  • Sensitive Personal Information (SPI) : personal information related to race, religion, politics, sexual orientation, medical history, biometric or genetic data as examples.
  • Data protection : regulations which govern how an organisation must protect personal information from unauthorised use.
  • Data privacy : regulations which govern the use of personal information by an organisation in respect to the privacy level set by the individual who is the legal owner.

As the largest Salesforce market by most measures, the USA is a good starting point for the discussion of data protection and privacy requirements. At the national level, historically the collection of personal information has not been restricted or regulated, instead the regulatory emphasis has been on harms prevention in specific sectors such as healthcare (HIPAA) , finance (GLBA) and education (FERPA) and for the protection of children online (COPPA). The American Data Privacy and Protection Act (ADPPA) is a proposed federal online privacy bill that is yet to be enacted into law. 2023 sees a number of states introducing state level data privacy statutes which, as with the federal ADPAA, align to the general principles of the European Union’s General Data Protection Regulations or “EU GDPR” introduced in 2018.

In many respects the EU GDPR serves as a best-practice reference which is informing the direction taken by emerging data protection and privacy regulations internationally.

The EU GDPR defines the strictest and most comprehensive set of data protection and privacy regulations globally. The personal information of EU residents is regulated for all businesses (or data controllers) that sell products or services to the EU, whether EU based or otherwise. The term extraterritorial describes this broad geographic applicability. The EU GDPR mandates that businesses operate in a transparent and accountable manner and enable individuals to exercise control over their personal information. In respect to international data transfers (such as those to Salesforce servers in the US), the EU makes an adequacy decision on a country-by-country basis as to the level of data protection and privacy controls in effect. Data transfers are allowed to countries deemed to be adequate, however data processor legal contracts or similar are required. For countries without an adequacy decision (including the USA) the contractual basis is stricter; in mitigation, the Salesforce data processing addendum incorporates EU-approved mechanisms including Processor Binding Corporate Rules and standard contractual clauses.

The key principles of the EU GDPR can be summarised as:

  • Fairness and Transparency – data subject (individual) should be notified about the personal information collected and its intended use.
  • Purpose Limitation – data processing activities should be limited to legitimate use.
  • Data Minimisation – only necessary personal information for the intended use should be collected.
  • Accuracy – collected personal information about an individual (or data subject) should be accurate.
  • Data Deletion – personal information should be retained only as required for the intended use.
  • Security – appropriate technical and organisational security measures must be employed to protect personal information against unauthorised processing and accidental release, access, loss, destruction,or corruption.
  • Accountability – data controllers must be able to demonstrate compliance (via record keeping, assessments etc.)
  • Individual Rights – data subjects have the right to request that a data controller provide access (incl. portability), correct, restrict use, and remove their data,and also to object to its use. Such requests are referred to as Data Access Subject Requests.

The EU GDPR regulations remain largely in effect in the United Kingdom (UK) post-brexit. The UK’s data protection regime (the Data Protection Act 2018) encompasses the UK GDPR, which is a retained version of the EU GDPR. There are some differences in terminology and scope, however the passage of time has not yet allowed divergence of any significance.

The privacy regime in effect in Canada is the Protection of Personal Information and Electronic Documents Act (PIPEDA). The PIPEDA regulations are federal in scope with exceptions for provinces with competing legislation. Whilst similar in intent to the EU GDPR, PIPEDA is applicable to private entities only, allows both implied and express consent (as opposed to express only) and provides significantly less rights to the individual. The Australia Privacy Act 1988 has similar differences to the EU GDPR as PIPEDA; less individual rights, less specificity in respect to consent etc. In both cases the EU GDPR regulations are generally more all encompassing, detailed and stringent in nature.

The privacy regime in effect in Japan is the Act on the Protection of Personal Information (APPI). The APPI was originally adopted in 2003 as one of first data protection regulations across the Asia Pacific region. Subsequent revisions have aligned the APPI with the EU GDPR such that both Japan and the EU have reached an adequacy decision which allows personal information to flow between the respective economies. The same adequacy decision exists for both Canada and the UK. As noted earlier, for the USA this is not the case and contractual arrangements such as the Binding Corporate Rules provide an alternative legal basis for data transfers.

With a focus on alignment to the EU GDPR regulations, the table below provides a high-level, indicative comparison of data protection and privacy regulations across key Salesforce markets.

USA 
1st & 2nd States by enforcement date
EUUKCanadaAustraliaJapan
Regulations / Key ElementsCalifornia – CCPA & CPRAVirginia – VCPDAEU GDPRDPA 2018 / UK GDPRPIPEDAPrivacy Act 1988APPI
Data Protection

(Data Controller Obligations)
Privacy by Design & DefaultXX
Record Keeping/TransparencyXXX
Data MinimizationXXXXXX
Security ControlsXXXXXXX
Informed ConsentX (SPI)XXXX
Legitimate UseXXXXXXX
Data Processor Legal ContractXXXXX
Breach NotificationX (no timeline)X (72 hours)X (72 hours)X (no timeline)X (no timeline)X
Data Protection OfficerXXX
Data Protection Impact AssessmentXXX
Data Privacy

(Data Subject Rights)
AccessXXXXXXX
CorrectionX (CPRA)XXXXXX
PortabilityXXXX
DeletionXXXXXX
Consent (sale/sharing)XX
Consent (direct marketing)XXXX
Consent (profiling)XXX
Consent (processing)XXX
Consent (for SPI)X
Object / AppealXXX
Private Right of Legal ActionXX
Non-discriminationXX
ExtraterritorialXXXXXXX
ApplicabilityBusinesses operating in California with
>$25M revenue
or, 50% revenue from selling/sharing PI or, buy/sell/share 100K California residents p.a.
Businessees operating in Virginia who control or process 100K consumers p.a. or, 25K consumers p.a. and >50% of revenue is derived from the sale of that PI. Entities offering products or sevices to the EU, or monitoring EU citizens.

Some exemptions for SME.
Entities offering products or sevices to the UK, or monitoring UK citizens.

Some exemptions for SME.
Canadian businesses that collect, use or disclose personal information in the course of a commercial activity.Businesses operating in Australia incl. Australian businesses with > $3M AUD revenue or trade in PI or provide health services or opted-in.Businesses that handle the personal information of individuals in Japan.
Public/Private EntitiesPrivatePrivateBothBothPrivateBothPrivate

Salesforce as a platform for customer data management provides tools and capabilities to help organisations manage compliance. Standard platform features enables consent to be recorded alongside the personal information which drives the typical operational processes supported by Salesforce i.e. marketing, sales and service. More sophisticated, perhaps multi-stage or multi-cloud, consent management processes can be implemented using the rich declarative and programmatic customisation options offered by the Salesforce platform. Where prefabricated, or industry-specific solutions are required the AppExchange provides a wealth of options; this is true also for the data quality and data management tools which can be imperative in delivering the unified view of the customer that is critical to compliance.

The table below describes the solution options (tools and capabilities) to consider when managing data protection and privacy compliance on the Salesforce platform.

Compliance Solutions
Standard FeaturesHyperforceHyperforce enables the public cloud deployment of Salesforce apps and services in mulitple global regions.

For example, the Hyperforce EU Operating Zone enables Salesforce customer data to be securely resident within the EU. Compliance requirements in relation to international data transfers are largely mitigated.
Privacy CenterPrivacy Xenter is a suite of data management tools installed by a managed package with secure off-platform storage via a Heroku Private Space. Heroku Data Retention Store data can be exposed in Salesforce core via External Objects.

Features:
(1) Automation of Customer Data Retention Policies.
Mask; anonymisation/pseudonymisation, library replace or, Delete; move to Heroku storage or hard-delete.

(2) Right to be Forgotten (RTBF) Policies.
Specify the related records to be deleted as a single action.

(3) Data Subject Requests / Portability Policies.
Portability Policies define the location of PI across Salesforce objects. The Portability API is used to collate data for a policy and generate a file and secure download link.

(4) Data Subject Requests / Privacy Requests.
Track DSR recorded in Privacy Centre via the PrivacyRequest object.

$$ Additional cost; license includes add-on credits to provision Heroku resources for the Data Retention Store.
Preference Manager
(Privacy Centre)
Create and publish Preference Forms (Apex or Template based) for secure self-service preference/consent capture via Experience Cloud or external website.
Data Protection and Privacy SettingsThe Consent Data Model introduces standard objects for the purpose of managing consent at multiple levels of granularity (global, engagement channel, contact point and data use purpose) plus the legal basis where applicable.

Global consent is recorded on the central Individual record; which can be related to a Lead, Contact, Person Account or User; or any combination thereof. Global consent includes privacy attributes such as:

Don’t Process / Profile / Solicit / Track
Forget this Individual
Export this Individual’s Data

With Data Protection and Privacy Settings active, Email Privacy can be enabled to prevent the send of both Commercial and Non-Commercial emails via Salesforce email tools, where the related flags above are set or the associated person record (Lead, Contact, Person Account) field Email Opt-out is true. The “Send Non-commercial Emails” user permission overrides the non-commercial send restriction however the user must confirm that the email being sent is non-commercail at send time.

Note, there are difference in the above statement in respect to Classic versus Lightning email tools.
Consent APIA REST API which aggregates consent for a specific action (e.g. process, email) across all available records for the individual and returns the most restrictive permission found. Either the Salesforce record Id or a contact point such as email address can be used to query consent.

The Consent Write API enables external systems to push consent changes which potentially update multiple records across the Consent Data Model. This API can also generate Individual records where required.
Consent Event StreamAn aggregated stream of change events that cover all objects in the Consent Data Model and also person obejcts such as Lead and Contact. Use this stream to push notifcations of consent changes to external systems.
Data ClassificationSalesforce provides metadata fields (Compliance Category, Data Owner, Sensitivity Level and Field Usage) which are used to classify data on all standard and custom objects. 

The Compliance Category picklist field can indicate the effective regulation i.e. GDRP, CCPA, PCI, HIPPA, PII.

Einstein Data Detect can be used to expedite the classification process using actual data.

Data Classification settings can guide decisions on Transaction Security and Shield Platform Encryption.
Sandbox Data MaskData copied to Full-copy and Partial-copy sandboxes can be automatically masked to ensure compliance. Field values can be randomised, replaced from a library or deleted. Salesforce Data Mask is installed as a managed package. The masking process can have a usability impact on the data; for example the library address data is US only.

$$ Additional cost.
Shield Platform EncryptionField-level data encryption at rest. It is common for regulations to require data to be secured at rest via strong encryption. Shield Platform Encryption supports probablistic and deterministic encryption schemes.  

$$ Additional cost.
Export DataSalesforce APIs and data loader can be used to extract customer data in response to a Data Access Subject Request.
Data Policies for Einstein featuresStandard features exist to enable exclusion from Einstein related maching learning models.
(Example) Custom SolutionsRight to be Forgotten (RTBF)
Anonymisation and Pseudonymisation
Organisations without access to Privacy Centre may develop custom solutions to automate the handling of requests to be forgotten. Techniques such as anonymisation and pseudonymisation can be applied in preference to record deletion.
Consent Data Model AutomationWith consent recorded on multiple records across the Consent Data Model it can be necessary to implement custom solutions which aggregate consent to an ulitmate yes/no decison or cascade down global consent changes.

Data archiving of consent changes (with reasons) to a Big Object is also a common custom solution.
Consent Synchronisation with Marketing Cloud The Salesforce Solution Kit Respect Consent Preferences in Marketing Cloud with the Consent Data Model describes the business use case and related custom solution approach for the synchronisation of consent between the Consent Data Model and Marketing Cloud. 
AppExchange 
Categories
Compliance ManagementTypical Features:
(i) Compliance process management (e.g. policy definition & automation plus procedure templates)
(ii) Data Subject Request management and automation.
(iii) Scanning and data masking.
Data ArchivingTypical Features:
(i) Customer data retention policy automation.
(ii) Secure, immutable data backups with restore functionality.
(iii) Sandbox data anonymisation.
Data ManagementTypical Features:
(i) Customer data de-duplication.
(ii) Policy based mastering of consent data.
(iii) De-duplication / aggregation of consent data.
(iv) Enforcement of regulatory requirements / corporate standards.

The Salesforce platform provides myriad options for the management of data protection and privacy compliance across international boundaries. For some Salesforce customers the completeness and automation offered by Privacy Center will be compelling. In other cases a combination of the solution options described above will be more appropriate. As an example solution approach, the Consent Data Model could be implemented to record consent and legal basis with a Custom Object and Flow for tracking of data access subject requests and AppExchange solutions for customer data de-duplication and retention policy automation.

In an increasingly regulatory international environment a clear understanding of the general principles of data protection and privacy regulation is imperative to delivering a secure, compliant Salesforce environment.

Resources:

Salesforce B2B Solution Architecture

This diagram (provided as a Miro board) covers high-level Salesforce B2B Solution Architecture concepts through a selection of multi-cloud scenarios (or flows). Provided as a technical reference for architects taking the new Salesforce B2B Solution Architect certification.

Miro Board Link


Salesforce B2C Solution Architecture

This diagram (provided as a Miro board) covers high-level Salesforce B2C Solution Architecture concepts, retail scenarios and C360 integrated experiences. Provided as a technical reference for architects taking the new Salesforce B2C Solution Architect certification.

Miro Board Link


Journey Builder Contact Re-entry

Please find below the findings of a recent investigation into Journey Builder Contact re-entry – where the concurrent journey injection relates to child records such as Opportunities or Purchases.

Problem

Where Journey Entry occurs at a Child-object level (Opportunity, Case or Purchase as examples), a given Contact may enter a Journey multiple times; the journey injection relates specifically and exclusively to the child record not the parent Contact.

When Contact Data attributes are referenced (by filter expressions) across one-to-many relationships there are no implicit filters applied that ensure that only the relevant Child-object record is referenced, i.e. the record that initiated the journey entry. Instead the first Child-object record (related to the Contact) that passes the filter conditions for a configured path will be utilised. This means that any child record (for the Contact) could drive the flow through each decision split within the Journey.

Solution A. Salesforce Data Events

Note, auto-generated Data Extensions related to Salesforce Data Event Entry Sources are created with all fields set to nullable, apart from the Primary Key (Primary Object ID).

A.1 Id field on the related Salesforce (Child) Object is the Foreign Key to the related Contact Data.

e.g. Entry Source = Purchase Data Extension (PK is Purchase Id). The required Contact Data for filter conditions exists in Purchase__c_Salesforce Sync DE. Here we can go ID field to ID field with an attribute to attribute comparison (which requires non-nullable fields).

In Journey filter expressions (specifically Decision Splits) add filter criteria to every path:

1) Journey Data > Event Source DE > Primary Object ID field
equals (Attribute-to-Attribute) Contact Data > (Synchronised or Standard) DE > Primary Object ID field (Primary Key)

The above ensures that the Contact Model filter references are restricted to the specific record that initiated the journey entry.

2) Add subsequent Contact Data filters using the target DE from (1) as the point of origin.

A.2 Non-Id field (other relationship field) on the related Salesforce Object is the Foreign Key to the related Contact Data.

e.g. Entry Source = Payment Data Extension (PK is Payment Id). The required Contact Data for filter conditions exists in Purchase__c_Salesforce Sync DE. Here we can’t go ID field to ID field instead the nullable FK field Purchase__c is the key into the Contact Model; being nullable an attribute-to-attribute comparison won’t work.

Link the auto-generated Entry Source Data Extension to the related (Synchronised or Standard) Data Extension with a new relationship in Contact Builder (Data Designer > Sales and Service Cloud Attribute Group).

In the Journey filter expressions (specifically Decision Splits) add filter criteria to every path:

1) Journey Data > Event Source DE > Primary Object ID field
equals (Attribute-to-Attribute) Contact Data > Event Source DE > Primary Object ID field

The above ensures that the Contact Model filter references are restricted to the specific record that initiated the journey entry.

2) Add subsequent Contact Data filters by selecting the Entry Source DE and navigating the new relationship added to the Synchronised Data Extension.

Solution B. Automation Studio Audience

In the Journey filter expressions (specifically Decision Splits) add filter criteria to every path:

1) Journey Data > Event Source DE > Foreign Key field (Could be the Primary Key field or any other field that holds the foreign key identifier value)
equals (Attribute-to-Attribute) Contact Data > (Synchronised or Standard) DE > Primary Key field (i.e. Primary Object ID)

The above ensures that the Contact Model filter references are restricted to the specific record that initiated the journey entry.

2) Add subsequent Contact Data filters using the target DE from (1) as the point of origin.

Additional Considerations

1) Journey Data returns the specific Entry Source DE record that initiated the Journey and provides the only means to establish a fixed reference for this record into Contact Data.
2) Exit Criteria can’t make reference to Journey Data and as such can’t be applied unless Journey Entry is at the Contact level not Child-object level.
3) The Update Contact Activity can’t make reference to Journey Data and as such can’t be applied unless Journey Entry is at the Contact level not Child-object level. This activity will update all child records for the current contact in the target data extension.

Salesforce Marketing Cloud January 2017 Release

icon-cloud-marketing

This post marks the first Salesforce Marketing Cloud related post on this blog, an event reflective of the increasing number of Salesforce implementations that span both the Salesforce and Marketing Cloud platforms (or cross-cloud, a term I can’t seem to stop using). Architects working on such implementations require a solid understanding of Marketing processes and both the functional and technical composition of the Marketing Cloud platform – not to mention the various APIs, connectors and 3rd party solutions offered via the HubExchange. Such a grounding is necessary to allow business processes (that are incidentally cross-cloud) to be understood and optimally implemented. This point is key; in ideal terms marketing processes should be integral parts of wider/deeper business processes that touch upon multiple areas of the business in pursuit of better customer experience or engagement. This type of thinking is key to realising current industry trends such as “Continuous Experience” where classic organisational structures (sales, service and marketing operations) are abandoned, or diminished, in favour of delivering unified customer journeys across all touch-points. For architects tasked with delivery of such solutions, the challenge starts with marketing domain knowledge and Marketing Cloud practitioner insight. In my own recent experience both stated aspects can benefit greatly from the combination of website/blog trawling, Trailhead and certification (Salesforce Certified Marketing Cloud Consultant). I completed the two required exams for this certification recently and found the experience challenging and time consuming but ultimately rewarding and definitely something I’d recommend to all Salesforce architects.

And so, on to the actual topic for this post – a review of the key features within the first of five major releases for the Salesforce Marketing Cloud scheduled for 2017.

The release notes are available here. The release is due to occur on the 27th January – this of course is subject to change.

– features are GA if not indicated otherwise

Marketing Cloud Connect – Sales & Service Cloud Activities
The ability to create Salesforce Activity records within a Journey Builder definition is now more intuitive via a new Lightning UI that abstracts the complexity of the WhatID/Who Id model for relating Activity records to Leads, Contacts and related records. Salesforce record interactions from within Journey Builder are key to blending the power of the two cloud platforms.

Content Builder – Themed Templates
Email messages can now be created from Themed Templates that encapsulate best practice for content creation. The templates provided cover Financial Services, Retail, Restaurant and Newsletter scenarios. The Themed Templates options can be found in the Define Properties step of the content creation flow.

Journey Builder – History Tab
The Contacts tab in the main Journey Builder navigation has been replaced with a History tab that displays the status of running journeys along with failure reasons to aid troubleshooting.

Marketing Cloud Mobile App
The January release brings an Android version of the mobile app and a new home dashboard for the iOS version. The Android version exhibits the same Lightning Experience UI and can be downloaded from the Google Play Store. The new app version will be released 2 weeks approximately after the main release date subject to Google/Apple app review. The new home page for the iOS version of the mobile app supports daily or weekly reminders and the delivers key performance statistics plus the current status of marketing automations. Note, the reminders work as push notifications and appear as badges on the app icon (as per email, SMS messages etc.). The new version of the iOS app also supports SMS campaigns via the SMS button in the primary navigation.

Social Studio – Emoji Support
Emojis come to life in the January 2017 release. The Publish component now supports the use of social network specific emojis within social content creation via the Emoji Picker (Composer and Inspector). Emojis are also correctly rendered by Engage and can be used to infer sentiment within Analyze thereby increasing accuracy.

Social Studio – Facebook Reviews
Social Studio now provides features to manage the reputation for a local Facebook page. Facebook reviews can be organised to filter promoters from detractors, automated actions can also be triggered based on review score. For example low scores could invoke a Journey Builder journey or Service Cloud case. Powerful stuff.

Social Studio – Analyze Dashboards
The Analyze component of Social Studio receives significant enhancement in respect to dashboards. The new release supports mixed dashboards showing content across multiple social accounts or topic profiles and expanded real time date options. Advanced card configurations enable filters, custom names and custom dimensions to be applied to individual cards within a dashboard.

Web Studio – Smart Capture to Lists
Previously Smart Capture Blocks defined within Content Editor were limited to Data Extensions for data push, with the January release this is extended to Lists.