Showing posts filed under:

Salesforce

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


Salesforce Data Architecture

This diagram provides a high-level overview of Salesforce Data Architecture concepts and platform capabilities. This is the first in a five-part Salesforce Architecture reference series covering core application and system architecture topics. I hope this series provides a useful reference for Salesforce Architects or those on the journey toward this role.

 

Salesforce Data Architecture (PDF)

Salesforce Summer ’20 Architect Highlights

I first published a release highlights post on this blog over 8 years ago; since that time the series has been renamed a few times but retained a focus on summarising the key technical aspects delivered with each release. I’ve always found preparing the content for the post a useful way to organise my own release readiness and feedback has indicated that amongst the plethora of release related blog posts available today there remains space for one with a technical slant. I hope so.

This post marks something of a relaunch to the series, this time with a strong focus on concerns significant to the Salesforce architect community (i.e. technical, solution or integration architects).

Release Timeline

Given the current global situation with COVID-19 the release timeline for Summer ’20 is approximately 1 month later than normal for a summer release. Each Salesforce release represents potential technical disruption for customers and managing this in parallel with the ongoing impact of the pandemic seems like an avoidable situation. The Summer ’20 sandbox preview is now scheduled for May 20-30th and the Summer ’20 production release is scheduled for June 12th (1st release window), July 10th (2nd) and July 17-18th *(3rd and final). As ever the trust site provides the full detail of the release timeline.

In advance of the sandbox preview window Summer ’20 pre-release orgs can be requested via the pre-release sign-up page. During the sandbox preview window Summer ’20 preview Scratch Orgs can be created by adding the release option (“release” : “Preview”) to the scratch org definition file.

The Salesforce Summer ’20 release notes are available from today at https://releasenotes.docs.salesforce.com/en-us/summer20/release-notes

 

Architect Highlights (in no order)

Application Architecture

Record-Changed Flows

Previously Before-Save Flows could be implemented to efficiently update Record field values during the before-commit phase of the record save transaction; historically this has been a strong ApexTrigger use case. For many implementations a significant improvement in record-save performance could be achieved by consolidating Processes and before-event ApexTrigger logic into a single Flow. Refactoring Process Builder Processes which served to populate field values on the same record only could achieve a remarkable reduction in save time which in turn delivers a more responsive end user experience and a potential reduction in CPU timeout errors. With Summer ’20 Before-Save Flows are now Record-Changed Flows which support before-save and after-save events; equating to before or after ApexTrigger events. In the former case the Flow is restricted to field value updates (via $Record) but the latter enables a wider range of Flow actions to be utilised.

This new capability enables Workflows and Processes to be reimplemented following a single Flow pattern which should achieve the best performance outcome.

Platform Event Flows

Process automation initiated via Platform Event has been possible with Process Builder up to now, with Summer ’20 this is extended to Flow Builder. Platform Event Flows represent an obvious next step on the emergence of Flow Builder as the hub for all things process automation.

With this model it is possible to build out complex business logic (declaratively) in Flow Builder which fires in response to on-or-off platform asynchronous events; a powerful combination particularly in the data integration context.

Flow System Context

Flows which are specified to run in System Context (that bypass the permissions of the running user) can now run outside of the Sharing Model (effectively Without Sharing in Apex terms). Previously System Context was limited to removing Object and Field Access permission checks with the Sharing Model record-level access checks enforced by the Flow execution.

Apex-Defined Type Flow Variables

An Apex-Defined Type is simply an Apex Object typically representing deserialised JSON response in a data integration scenario. ADT variables could historically be utilised within Flows but could not be passed into the Flow from the calling context. With Summer ’20 it is now possible to hand-off callout response processing to a Flow, as one example use case. Whilst a seemingly minor change this opens up Flow as viable option for defining business logic for key use cases that would otherwise have required Apex code.

Dynamic Forms (Non GA Preview)

Undoubtably one of the most eagerly anticipated features for some time Dynamic Forms makes its preview debut in the Summer ’20 release. The Dynamic Forms feature is billed as an upgrade to Page Layouts where UI composition (sections, fields and visibility logic) occurs directly within Lightning App Builder. Preview support is limited to custom objects and excludes record pages that use pinned-region or custom page templates.

Lightning Message Service

The Lightning Message Service provides a standardised mechanism for communication across components on a page or across pages. Supported component types include Visualforce Pages, Aura Components and LWC. Communication is facilitated by Lightning Message Channel subscription and publication.

Development Lifecycle

Source Tracking in Sandboxes (Beta)

The source tracking deployment type is now supported for the developer sandbox types (Developer and Developer Pro); previously source tracking was restricted to Scratch Orgs. Source tracking enables efficient synchronisation of changed metadata between the local environment and the Salesforce org. Where existing development or release management processes (i.e. build automation and CI) are yet to be transitioned to Scratch Orgs this capability offers increased efficiency and accuracy as tracking of the changed metadata state is managed by the platform.

Org Dependent Unlocked Packages

Most Salesforce implementations suffer from a legacy accumulation of metadata components built up over a period of time by multiple projects, teams and partners. In such cases the benefits of implementing a structured Unlocked Package approach can appear to be unrealistic due to the degree of interdependency across the environment. With Org Dependent Unlocked Packages, metadata validation (i.e. dependency checking) can be deferred to the time of package installation, rather than during package version upload. Org Dependent Unlocked Packages can be created with the orgdependent Salesforce CLI parameter.

Security Architecture

Initiate Two Factor Authentication (2FA) with Apex

Two new methods have been added to the System.UserManagement class to enable Apex initiation of 2FA verification (e.g. Salesforce Authenticator). One method initiates a 2FA verification service (initVerificationMethod), the second completes the verification (verifyVerificationMethod).

Highly Trusted Users

The new “Skip Identity Confirmation at Login” permission allows users to login without second factor identity verification. Clearly one to use with a high degree of caution but useful for certain use cases where 2FA is impossible or impractical.

Minimum Access User Profile

The new “Minimum Access – Salesforce” User Profile provides a base profile for the Salesforce user license type defined following the principles of least privilege, a well-established security best practice. This profile can be cloned and extended as required or used in concert with Permission Sets. This support for a secure-by-default model feels long overdue.

Integration Architecture

Async Platform Event Publish Operations (Pilot)

The initial success of a Platform Event publication can be straightforward to determine (e.g. access to the SaveResult in Apex code) but the eventual state of the event is not accessible. To address this gap a new standard Platform Event (PlatformEventStatus) has been added; subscribers (e.g. ApexTrigger) are pushed status updates for High Volume Platform Events that have the “Track Publish Status” setting enabled.

Functional Architecture

Service Cloud. Omni-Channel Status-Based Capacity Model

Previously Omni-Channel tracked Agent capacity by the number of open tabs within the Agent Console. For short-lived Work Items (e.g. Case or Lead) that are resolved within a single user session the tab-based capacity model is often appropriate and can work well. However, this is not the case where Work Items are longer-lived and have a lifecycle that spans multiple user sessions or days: this leaves Omni-Channel a poor fit for many service operations. To address this Omni-Channel can now be configured to track Agent capacity based on the status of the Work Items that the Agent owns. The new Omni-Channel setting “Enable Status-Based Capacity Model” is used to switch between the default tab-based capacity model and the new status-based model. This could be a game changer for Omni-Channel given the importance of capacity management to service operations and the limitations of the tab-based model.

ISV

Delete Lightning Components from Managed Packages

A long awaited capability for ISV to delete obsolete Lightning Components from released Managed Packages. From personal experience I know how easy it has been over the last few years to build a legacy of old components in the package following refactoring and transition from Aura to LWC. Note, component deletion must be enabled in the Packaging Org (via Salesforce Support Case).

First Generation Managed Package Conversion (Developer Preview)

The Summer ’20 release includes a developer preview for the conversion of first-generation managed packages to second-generation managed packages. The preview is limited to Scratch Orgs and is intended to communicate how this long-awaited capability will function in due course. Personally, I’m looking forward to bringing the benefits of second-generation packaging to previously released managed packages.

Salesforce Package Versions

In the new world of second generation packaging (2GP) capabilities such as Unlocked Packages mean the technical aspects of packaging are no longer a concern only for ISV developers but are now equally applicable to enterprise development. The Salesforce Developer Experience (SFDX) developer guide documentation provides a great reference for those getting started with packaging which covers all the main implementation considerations. One area that isn’t covered is the management of package versions in practice; I call this a package version scheme, an example of which is included below.

Package Version Scheme:

Convention [Major.Minor.Patch.Build]

    Pre-release development; 0.1.0-x .. 0.2.9-x

  • First-release; 1.0.0-1
  • Post-initial-release bugfixes; 1.0.1-x .. 1.0.3-x
    (Patch number must increment per package version release)
  • Post-initial-release internal builds; 1.1.0-x
    (Only the Build number must increment per package version release)
    Next-release (minor enhancement); 1.1.0-x (Release with the final build number)

  • Post-minor-release bugfixes; 1.1.1-x .. 1.1.3-x
    (Patch number must increment per package version release)
  • Post-minor-release internal builds; 1.2.0-x
    (Only the Build number must increment per package version release)
    Next-release (major enhancements); 2.0.0-1

  • Post-major-release bugfixes; 2.0.1-x .. 2.0.3-x
    (Patch number must increment per release)
  • Post-major-release internal builds; 2.1.0-x
    (Only the Build number must increment per release)

Additional references:
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_manpkgs_package_versions.htm
https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_intro.htm