Cross Cloud Data Models Solution Kit
DOWNLOAD
First things first !
To download this implementation guide, click the download button below.
If you need more information about the implementation guide, you can read the Table of Contents below.
Explore CrossCloud
Engagement Data Models
Salesforce Spring
salesforcedocs
Last updated November
Copyright Salesforce Inc All rights reserved Salesforce is a registered trademark of Salesforce Inc as are other
names and marks Other marks appearing herein may be trademarks of their respective owners
CONTENTS
Explore CrossCloud Engagement Data Models
Understand Salesforce Systems of Record
Integrate Service Cloud Marketing Cloud and Commerce Cloud with Integration Reference
Implementations
Understand the Flow of Data
Build a Common BC Person Model
Use Person Model Considerations
EXPLORE CROSSCLOUD ENGAGEMENT DATA MODELS
Improve customer loyalty by establishing a common profile for each customer across Marketing Cloud BC Commerce and core platform
clouds Determine the best system of record for each type of customer data to take advantage of outofthebox cloud integrations
Get Started
Explore system architecture related to this solution
BC Industry Blueprint
BC Reference Architecture
BC Solution Architectures
Take Trailhead modules related to this solution
Salesforce Solution Kits Quick Look
Customer Guide for Retail Quick Look
Customer Guides Quick Look
The Explore CrossCloud Engagement Data Models solution kit helps you
Explore concepts for modeling data on the platform
Map customer business requirements and definitions to product capabilities
Optimize your crosscloud implementations to achieve a degree view of your customers
Establishing the best systems of record and data integration patterns for your organization helps you
Apply bestinclass marketing tools for commerce transactional messaging
Surface email tracking and engagement views for customer service agents
Required Products
Commerce Cloud SFRA or SiteGenesis
Marketing Cloud Enterprise
Sales Cloud Service Cloud or Experience Cloud
Marketing Cloud Connect
Explore CrossCloud Engagement Data Models
Understand Salesforce Systems of Record
Optional Products
Salesforce Privacy Center
Data Cloud
Mulesoft
Implement This Solution
Understand Salesforce Systems of Record
Optimize your crosscloud integrations by understanding which cloud is the ideal system of record for which piece of data
Integrate Service Cloud Marketing Cloud and Commerce Cloud with Integration Reference Implementations
Reference implementations allow actions to be made in one cloud based on activity in another cloud
Understand the Flow of Data
Marketing Cloud Salesforce BC Commerce and Service Cloud can be connected both with Connectors and other APIbased
integrations
Build a Common BC Person Model
Salesforce lets you build a model of a person based on person accounts on accounts and contacts together or on a combination
of accounts contacts and person accounts
Use Person Model Considerations
Many objects and record types in Sales Cloud and Service Cloud include data to define people Each of these objects has a slightly
different primary purpose
Understand Salesforce Systems of Record
Optimize your crosscloud integrations by understanding which cloud is the ideal system of record for which piece of data
In Salesforce each cloud contains information about customers but the information can differ between clouds Determining the correct
system of record for each piece of data is an important step to building highly functional crosscloud solutions
We recommend storing primary attributes about your customer in a core platform cloud such as Service Cloud or Sales Cloud Experience
Cloud is also a possibility
When Should a System Be Authoritative
Consider these recommendations for the role of each cloud when establishing data source authority in your multicloud implementations
Sales Cloud Service Cloud and Experience Cloud
Primary person attributes such as name address birthday phone and email
Consent and compliance preferences
Case management information including transactions history and sentiment
Recency snapshot for orders and engagement
Subscription preference information across all channels
Order history
Explore CrossCloud Engagement Data Models
Integrate Service Cloud Marketing Cloud and Commerce
Cloud with Integration Reference Implementations
Marketing Cloud
Lifetime engagement tracking and history
Suppression lists
Subscription preferences
Other data for personalization or segmentation
Customer journey flow
Counsel and compliance preferences
BC Commerce
Ecommerce transactions including order records
Customer product affinity
Customer group membership aligned with ecommerce strategies
Promotion eligibility
Mulesoft
Mulesoft provides a widely used integration platform for connecting applications data and devices in the cloud and on the premises
Mulesoft also provides a powerful tool to transform data with DataWeave Discover and use prebuilt assets from the MuleSoft ecosystem
or use Mulesofts Anypoint Exchange to save share and reuse internal best practices MuleSoft Accelerator for Retail includes prebuilt
APIs connectors integration templates and reference architecture to enable retail IT teams to jumpstart digital transformation initiatives
Heroku
While Heroku isnt a system of record it can tightly integrate with core platform clouds such as Sales Cloud and Service Cloud Heroku
can aggregate data such as lifetime and historic records from several source systems when building customer applications at scale Use
cases include data lakes preprocessing and transforming records for other clouds As a result Heroku as a platform can host various
systems of records
Related Content
Review this solutions use case and purpose
Explore CrossCloud Engagement Data Models on page
Take the next steps in this implementation
Integrate Service Cloud Marketing Cloud and Commerce Cloud with Integration Reference Implementations
Understand the Flow of Data
Integrate Service Cloud Marketing Cloud and Commerce Cloud with
Integration Reference Implementations
Reference implementations allow actions to be made in one cloud based on activity in another cloud
To integrate these clouds rely on the contact record ID as a common key
Explore CrossCloud Engagement Data Models
Integrate Service Cloud Marketing Cloud and Commerce
Cloud with Integration Reference Implementations
General Information about Integration Reference Implementations
Plan your implementation as you would any other BC Commerce feature by collecting requirements capturing work tasks and
making task estimates
The reference implementations provide reusable code to accelerate pointtopoint integrations between BC Commerce and
Marketing Cloud or Service Cloud
In general dont use the bccrmsync reference implementation as a way to initially load the data
To ensure back and forth data flows pay attention to implementation considerations around primary keys between clouds Marketing
Cloud Connect requires the Contact ID in Service Cloud to be the primary subscriber and contact key
Reference implementations are developerenablement frameworks that accelerate crosscloud integration by providing code
configuration and implementation patterns
Reference implementations support a core set of use cases that can extend to support other customerdriven use cases
Reference implementations require customization and configuration in Marketing Cloud and BC Commerce The BC Commerce
storefront requires customization as part of the integration
Implementation and validation require operational and administrative experience with Marketing Cloud
Primary IDs for People
Outofthebox pointtopoint crosscloud integrations
Use the Sales Cloud and Service Cloud contact record ID as the primary ID across the Salesforce platform
Marketing Cloud has a contact key in Contact Builder designed to be the crosschannel customer ID The customer creates this ID
whenever they define an audience It happens when they configure data synchronization in Marketing Cloud Connect or use Journey
Builder integrations with Sales Cloud or Service Cloud
Email Studio email and Mobile Connect SMS register subscriber keys for their respective channels Those applications use contact
keys and subscriber keys for subscription management and identifying contacts for consent and compliance
In BC Commerce CustomerID is the systemgenerated ID for a customer whereas CustomerProfilecustomerNo is the number that
identifies customers
Key considerations
Avoid using email addresses SMS or other channel addresses as the contact key in Marketing Cloud
To simplify consent compliance and the General Data Protection Regulation GDPR logical model use a Salesforce record ID as a
single unique identifier This identifier applies across channels and clouds
Marketing Cloud Connect uses the contact record ID from Sales Cloud or Service Cloud to return email tracking data back into CRM
Set up the BC Commerce Customer record with the Salesforce ContactID The bccrmsync reference implementation includes
builtin patterns to help with this process
Using a Salesforce contact record ID simplifies integration with Experience Cloud and BC Commerce
If your system doesnt require Marketing Cloud Connect functionality you can use an external customer ID across all clouds
Related Content
Review earlier steps in this solution
Understand Salesforce Systems of Record
Explore CrossCloud Engagement Data Models
Understand the Flow of Data
Take the next steps in this implementation
Understand the Flow of Data
Build a Common BC Person Model
Use Person Model Considerations
Understand the Flow of Data
Marketing Cloud Salesforce BC Commerce and Service Cloud can be connected both with Connectors and other APIbased integrations
Commerce Cloud to Marketing Cloud Integration Reference Implementation
Engages customers via transactional messaging and personalized journeys
Manages customer subscription preferences via the storefront
Delivers personalized product recommendations via email messaging
Recaptures lost revenue via abandoned cart and browse
Marketing Cloud Connect Connector Product
Provides configurable options for replicating Service Cloud contact lead and user data including related objects to Marketing
Cloud
Integrates Journey Builder directly with Sales Cloud and Service Cloud records The connector triggers journeys based on record
creation and updates It provides options for updating and creating data in Salesforce from within a journey
Exposes customer engagement data and history to Sales Cloud and Service Cloud Users view counts of actions such as opening
emails or clicking a contact record page
Commerce to Service Cloud Integration Reference Implementation
Deflects highvolume and lowcomplexity cases with selfservice
Provides agents with updated customer profile data
Explore CrossCloud Engagement Data Models
Understand the Flow of Data
Turns service interactions into upsell opportunities by placing an order on behalf of a customer
Drives genuine conversations with shoppers in their preferred channels
Alternative Flow of Data
Data Cloud
Extract using Starter Data Bundles or Data Extensions
The Order Bundle starter bundle creates one or more data streams to flow data from a BC Commerce source The data bundle
automatically creates and maps data streams
Starter data bundles are also available for the Salesforce CRM source including Sales Cloud Service Cloud and Loyalty Cloud These
bundles automatically map the data source objects to the data model objects DMO and establish DMO relationships that improve
your segmentation results
Use Segmentation to break down your data into useful segments to understand target and analyze your customers Create segments
on any entities from your data model and then publish them on a chosen schedule or as needed
Activation is the process that materializes and publishes a segment to activation platforms including Marketing Cloud BC Commerce
and Service Cloud
Related Content
Review earlier steps in this solution
Understand Salesforce Systems of Record
Integrate Service Cloud Marketing Cloud and Commerce Cloud with Integration Reference Implementations
Take the next steps in this implementation
Build a Common BC Person Model
Explore CrossCloud Engagement Data Models
Build a Common BC Person Model
Use Person Model Considerations
Build a Common BC Person Model
Salesforce lets you build a model of a person based on person accounts on accounts and contacts together or on a combination of
accounts contacts and person accounts
Modeling BC Customers in Salesforce Using Person Accounts
Benefits of person accounts
Combines account and contact object attributes to create an independent person without having to attach them directly to an
existing business account
Works with core object functionality
Handles the mixing of BB and BC relationships
Connects a person account to a business contact via contact relationship
Key considerations
Reverting from person accounts isnt available
You manage contact security at the account level
The record appears only in account search results
Merging regular contacts and person accounts isnt possible
Merging two site members that are person accounts isnt possible
Sometimes person accounts require more data storage
Some AppExchange offerings arent compatible with person accounts
Integration Considerations Around Person Accounts
While not obvious from the detail page a person account is actually a combination of two records into one view
Contact Record AccountPersonContactID
This contact record associated with the person account contains attributes about the person The caseinsensitive digit CRM
record ID for this contact record acts as the unique ID for the person across the platform behind the scenes You connect with people
not accounts
Account Record AccountID
This account object presents itself in Salesforce as a combination of contact and account fields In the data model the Account object
and the Contact object contains a boolean flag that determines whether the record is a Person Account
Use extra fields on the underlying contact record when its data related to people and on the account record when its account data
Use No RoleHierarchyBased access control
Explore CrossCloud Engagement Data Models
Use Person Model Considerations
Person Accounts and Marketing Cloud Connect
Marketing Cloud Connect has several ways to create records including Journey Builder integrations With both of these interfaces
Marketing Cloud Connect maps keys to contact lead and user records No other objects create Marketing Cloud contacts
Implications for person accounts
When you sync the contact object to Marketing Cloud it brings both records
Business Account Contacts isPersonAccount False
Person Account Contacts isPersonAccount True
When you sync the account object to Marketing Cloud it maps to the related contact record Marketing Cloud Connect respects
Salesforce object dependencies It brings both records
Business Accounts isPersonAccount False
Person Accounts isPersonAccount True
Marketing Cloud Connect creates Marketing Cloud contact subscriber records for all Salesforce records Avoid creating an audience
in which the Marketing Cloud contact key points to a Salesforce account record ID This duplicates and fragments Marketing Cloud
contacts
Related Content
Review earlier steps in this solution
Understand Salesforce Systems of Record
Integrate Service Cloud Marketing Cloud and Commerce Cloud with Integration Reference Implementations
Understand the Flow of Data
Take the next steps in this implementation
Use Person Model Considerations
Use Person Model Considerations
Many objects and record types in Sales Cloud and Service Cloud include data to define people Each of these objects has a slightly
different primary purpose
Individual Object
For compliance use cases Individual helps aggregate compliance flags for data related to people in Sales Cloud and Service Cloud
Use this records boolean flags to capture master privacyrelated preferences To build out any customer consent and compliance
solutions use the preferences across the Salesforce platform
Design solutions to use these flags Changing the boolean setting doesnt propagate those changes across the platform
For use cases involving an individual record and multiple records related to people in Salesforce
Establishing relationships between contacts and leads on an individual record is a manual assignment effort
Explore CrossCloud Engagement Data Models
Use Person Model Considerations
Consider associating an individual record with one contact or lead Those records usually include channel address information along
with other personally identifiable information Because Marketing Cloud Connect creates a unique contact for each record using
lead and contact fractures the view Its more difficult to manage data this way
You can associate one lead contact or user with only one individual record
When synced to the Marketing Cloud individual records link to the Marketing Cloud Contact Model through one of the three human
record types Individual record IDs arent subscriber keys
Managing Consent and Privacy
Proper data management helps ensure that businesses comply with legal regulations and avoid penalties
Sales Cloud and Service Cloud offer the opportunity to extend your org with Consent Management objects that track and store certain
data privacy preferences
Salesforce Privacy Center uses a managed package and Heroku to securely store your Salesforce data
To obfuscate customer data Privacy Center can replace your customers data with either random characters known as anonymization
or mock data known as pseudonymization
Privacy Center can also retain customer data by putting it into storage using Heroku Connect While this data is retained it cant be
processed or accessed by other users
Privacy Center can completely delete a users record and any related information from your Salesforce org Unlike retained data
these records are permanently deleted after the Recycle Bin clears either through manual clearance by a user or after the day
expiration limit
Leads
Lead records include details about people who are interested in your products and services Salesforce stores lead details in lead records
that sales reps can convert to contact records
Lead status is an engagementlevel attribute This record reflects the degree to which the person engages with your company or
brand
Some leads never convert to contacts Archive or clean up those unqualified leads
The lead conversion threshold in which the lead becomes a contact is arbitrary and varies by customer Each company has different
engagement methods and definitions for converting leads to contacts
Lead conversion requires careful planning around consent and compliance use cases People dont know or care about how you
model their data But they expect your company to track and manage their consent for them
Leads create a standalone Marketing Cloud Contact record
In Marketing Cloud a lead is an actual contact and not a transitional record You manage profiles preferences consent and compliance
for each of them independent of any converted contact record
Merging and converting leads isnt available in Marketing Cloud A lead is a legitimate contact in Marketing Cloud even after a lead
conversion in Sales Cloud or Service Cloud Its important to manage preferences and consent processes associated with the new
contact in a crosscloud sense to account for the legacy Marketing Cloud lead
Leads in Sales Cloud and Service Cloud help with contact record data quality but they can damage the data quality in crosscloud
implementations
Learn the advantages of using the Contact object instead of the lead object
Contacts can include multiple record types to simulate the lead conversion process similar to opportunity stages for an opportunity
record Account for other possible lead integration points and include an archival strategy
Explore CrossCloud Engagement Data Models
Use Person Model Considerations
A stable customer ID lets you establish one customer ID that spans all Salesforce clouds This ID helps with any use cases that require
a lifetime view of the customer
To support each phase of the contacts journey using Lightning Experience group and present field sets with different custom
attributes based on type
Stable record IDs retain the contact ID when the type changes Custom flows create records or propagation of duplicate keys across
the platform fracturing the contact view
You can associate contact records with multiple accounts including person and business accounts
Access Control creates a combination of page layouts sharing rules and custom profiles to control the type and attribute visibility
For example users who engage with only one type of contact can minimize record clutter in the platform
Alternatively you can use the Lead object to bring in deduplicate and assign the data related to people to your model This process
converts the lead to a contact record before using crosscloud capabilities
Accounts and Contacts Modeling People in Salesforce
Contacts are typically linked to accounts which allows you to model the structure of a household or organization Modeling people
with contacts and accounts has several benefits
Original structure offered by Salesforce
Supports BB and BC
Maps to standard Salesforce structure
Simplicity of reporting and data migration
Supports thirdparty integration
Its important to consider
Data storage implications
Definition of household entity
Integration of both objects
Data integrity triggers to enforce consistency between household and contact
Lead conversion implications
Integration Considerations Around the Contact Object
Standard Account and Contact Relationship
The primary account relationship that a contact has informs its security model and ownership settings
You need sufficient information about a contact typically BC to populate an account object
Secondary relationships can relate to multiple accounts
Alternate Contact and Account Relationships
Linking consumer contacts to a bucket account such as brand geolocation and product line is easier for smaller data volumes This
relationship has performance limitations including data skew when assigning more than people to an account
Avoid using an orphan contact model unless you have no other option because it limits security ownership reporting and
AppExchange packages
Consider setting up a type of contact record to mimic a lead engagement funnel
Using record types on the Contact object restricts views and workflows for contact records by type You can improve this situation
by using the Lead and Contact objects but one contact record is best for crosscloud data quality
Explore CrossCloud Engagement Data Models
Use Person Model Considerations
Avoid duplicating Sales Cloud and Service Cloud customer records before using Marketing Cloud Connect
Establish a dayzero practice across all systems Avoid using duplicate records in processes such as legacy capture forms via Web
Collect and WebtoLead
Avoid pickawinner duplication solutions in Sales Cloud and Service Cloud after integration This solution doesnt address perchannel
subscription preferences or compliance requests and fractures engagement history in crosscloud implementations
If you want to manage storage and indexing issues consider implementing an archival solution Instead of deleting the records
move them into big objects or off the platform This process retains the original record ID which helps reconnect with crosscloud
data stores
Converting leads to contacts creates duplicate keys in Marketing Cloud
To avoid duplicate records avoid synchronizing or sending messages to leads via Marketing Cloud Connect
Using leads to capture data from external systems creates duplicate records Check them against contacts in Sales Cloud and Service
Cloud Convert or merge them to synchronize with Marketing Cloud
Bring only quality contacts into Marketing Cloud
Avoid using the contact delete framework in Marketing Cloud to delete duplicate records or remove lowquality contact records to
solve billing challenges
Work with Salesforce Customer Support to delete these records for onetime cleanup efforts or use the contacts delete framework
Limit calls to fewer than one million records at a time
When You Already Have Marketing Cloud and Add Service Cloud
Many of our customers have Marketing Cloud and want to add Sales Cloud or Service Cloud So they establish a Marketing Cloud contact
key that isnt a Salesforce record ID But our guidance for crosscloud data flow requires the use of a Salesforce record ID In this case
these customers have two paths forward
Create contact records in Marketing Cloud for each person using the Salesforce record ID
Note This path causes duplicate contact records Each record has its own subscription management consent compliance
requirements and fragmented engagement history This solution is acceptable only if you manage the legacy contact records
through an archival process
Engage Marketing Cloud Professional Services to perform a subscriber key migration This path replaces subscriber and contact keys
in Marketing Cloud with the new Salesforce contact record ID The replacement happens in all Marketing Cloud system tables and
sendable data extensions After the migration all Marketing Cloud contacts include Salesforce contact record ID keys You manage
subscriptions and compliance with one view of engagement history and one record
Note A subscriber key migration causes an email sending outage while the migration is under way Plan accordingly with
your services team When using Marketing Cloud Connect complete the subscriber key migration before synchronizing the
contact lead or user records Otherwise your migration can fail
Related Content
Review earlier steps in this solution
Understand Salesforce Systems of Record
Integrate Service Cloud Marketing Cloud and Commerce Cloud with Integration Reference Implementations
Understand the Flow of Data
