Ways to Leverage Data Cloud Copy Fields and Related Lists
Let’s say you have a typical Sales or Service rep. Their Admin has set up some cool new insights in Data Cloud, but the rep has no clue how to access that data. Reps are used to their CRM apps; they aren’t about to open Data Cloud and start scrolling through Data Model Objects (DMOs) and Calculated Insight Objects (CIOs). Everyday Salesforce users need Data Cloud insights to be integrated into their normal workflows.
Enter Data Cloud Enrichments: the easiest to get your data from Data Cloud into Salesforce CRM. There are two kinds of enrichment:
- Copy Fields: transfer data 1:1 from objects in Data Cloud to objects in CRM
- Related Lists: list records from Data Cloud objects on record homes of CRM Objects.
This post will walk through several use cases for both Enrichments, showcasing how they fit into the Data Cloud flow (shown below) and helping make Data Cloud an integrated part of the Salesforce experience.
Note: For a detailed step-by-step approach check out this related blog on copy fields and related lists.
Copy Fields
A Copy Field Enrichment lets Admins map fields in a Data Cloud object to fields in a CRM object. As of the Spring ’24 release, objects used in Copy Fields need to meet the following conditions:
- Source Objects: DMOs/1-dimensional CIOs (with a 1:1 relationship to either the Individual DMO or the Unified Individual DMO)
- Target Objects: Contact/Lead.
Note: We are working on expanding support to include more objects in upcoming releases.
Setting up a Copy Field Enrichment end-to-end in Spring ’24 typically takes the following steps:
- Data Ingestion: Stream Contacts/Leads from a Salesforce org and map them into the Individual DMO.
- Data Processing: Create insights in Data Cloud (Einstein Studio Predictions, Identity Resolution, Calculated Insights, etc).
- Prep Data for Copying: Create custom fields on a Target Object to store Data Cloud data (as existing data in targeted fields will be overwritten).
- Enable key permissions on these fields, as listed in the official help doc.
- Create a Copy Field: Go to the Object Manager page of the desired Target Object and go to the Copy Field tab. Hit “New”, select the desired Source Object/Fields, map them to the desired Target Object/Fields, and Activate.
Now let’s take you through a few use-cases of increasing complexity, breaking down how the copying process plays out.
Use Case 1: Einstein Prediction DMO
Say the Admin ingested some Contacts into the Individual DMO, and now they’ve run them through Einstein Studio to predict their likelihood to respond to a call.
- The results are output to a custom DMO, named Call Prediction DMO.
- The key prediction is output into a field called Response Odds, with options “High”, “Med”, or “Low”.
- The Individual ID for each record is also output into a field “Individual Key”.
- The Admin uses “Individual Key” to create a new 1:1 relationship between the Call Prediction DMO and the Individual DMO.
With that setup, the Admin creates a new Copy Field on Contact. They select Call Prediction DMO as the Source Object, and then they map Response Odds onto a custom field.
In this case, the Copy Field will look through each Call Prediction record’s matching Individual record. It will then take the Individual Id and see if it matches an SFID on Contact. If it does, the field gets copied.
Now, if a Sales Rep wants to know if it’s worth calling a certain Contact, they can just go to that record’s details in Sales Cloud and look at the Predicted Call Response Odds field, which originated from Data Cloud.
Use Case 2: Unified LTV CIO
Say the Admin ingested some Contacts from a Salesforce org into the Individual DMO, and they’ve ingested some Sales Orders from Amazon S3. Now they want to calculate how much each Unified Individual has spent with a Calculated Insight.
- The Sales Orders have a field linking them to Individual IDs.
- The Admin runs Identity Resolution on the Individual DMO, which generates a Unified Individual DMO and a Unified Link Individual DMO (which maps Unified Individual IDs to Individual IDs).
- The Admin creates a Calculated Insight that joins Unified Individual → Unified Link Individual → Individual → Sales Orders, effectively joining all Sales Orders related to each Unified Individual.
- The Admin then sums each Sales Order’s cost, grouped by Unified Individual ID, getting the Unified Lifetime Value (LTV).
- The Admin then saves the Calculated Insight. This outputs the Unified LTV CIO, which has two fields: Unified Individual ID (the single dimension), and Unified LTV.
With that setup, the Admin creates a new Copy Field on Contact. They select Unified LTV CIO as the Source Object, and then they map Unified LTV onto a custom field.
In this case, the Copy Field will look at each CIO record’s Unified Individual ID and see what records it matches in the Unified Link Individual DMO. It will then take the corresponding Individual ID and see if it matches an SFID on Contact. If it does, the field gets copied.
Now, if a Sales Rep wants to see if someone is a high-value Contact, they can just go to that record’s details in Sales Cloud and look at the Unified LTV field, which originated from Data Cloud.
Use Case 3: Unified LTV CIO across Orgs
Say the Admin ingested some Contacts from Salesforce Org A and from Salesforce Org B. They mapped both into the Individual DMO and they’ve ingested some Sales Orders from Amazon S3. They want to use a CIO to calculate Unified LTV for each Contact, but the Sales Orders only match Contact ID’s in Org B.
In this case, the Admin can still get Unified LTV onto Org A contacts using Identity Resolution (IR).
- They run IR to make Unified Individual profiles, recognizing Individuals that are the same across Org A and Org B.
- They create the Unified LTV CIO as done in Use Case 2, joining Unified Individual → Unified Link Individual → Individual → Sales Order.
- Even though all the Sales Orders get joined to Individuals from Org B, they are then joined to a Unified Individual that includes Individual IDs from Org A.
Now, when the Admin copies from the Unified LTV CIO to Org A Contacts, the Unified LTV score copied will still reflect any Sales Orders belonging to unified Org B Contacts.
By default, the Copy Field job will filter by Data Source ID. So, when copying to Org A, it will only try to copy records that have a Data Source ID matching Org A. Data Cloud records originating from Org B won’t match the Salesforce IDs of records in Org A, so they are filtered out as an optimization.
Use Case 4: Einstein Prediction DMO on External Data Sources
Say the Admin also ingested some Contacts from two non-Salesforce Data Sources. Perhaps they were involved in some external automation and the Admin streamed them in via Amazon S3, then mapped them to the Individual DMO. The Admin knows these S3 records have IDs that match some SFIDs in Org B, but by default, the Data Source ID filter would filter them out.
This can be solved by overriding the default Data Source ID filter with a Key Qualifier filter. Key Qualifiers are a field that Admins can append to all records in a Data Lake Object. So, if the Admin wants to indicate that records from both S3 streams correspond to the same Org, they could add a KQ called “OrgB” to each DLO.
Now, say the Admin creates another Call Prediction DMO, as done in Use Case 1. When creating a Copy Field enrichment on Org B, the Admin can change the filter to copy all records with the “OrgB” Key Qualifier, allowing the external records to get copied if they match Salesforce IDs.
Related Lists
A Related List Enrichment lets Admins create a Lookup Relationship from a DMO to a CRM Object. Admins can then use this Lookup to create a Related List of DMO records on a CRM Record Home. As of the Spring ’24 release, objects used in Related Lists need to meet the following conditions:
- Data Cloud Objects:
- Unified Contact Point Objects (ex: Unified Indv Contact Point Phone).
- Engagement DMOs with an “effective” N:1 relationship to the Unified Individual/Account DMOs via the Individual/Account DMOs.
- Individual/Account has a N:1 relationship with Unified Individual/Account.
- If the Engagement DMO is N:1 or 1:1 with Individual/Account, it’s N:1 with Unified Individual/Account.
- CRM Objects: Contact, Lead, and Account.
Note: We are working on expanding support to include more objects in upcoming releases.
Setting up a Related List Enrichment end-to-end in Spring ’24 typically takes the following steps:
- Profile Data Ingestion: Stream Contacts/Leads into the Individual DMO or Accounts into the Account DMO.
- Identity Resolution: Create Unified Individual/Account profiles, as per the official help doc.
- Engagement Data Ingestion: Stream in the Engagement records and mark their Category as Engagement.
- Engagement DMO Setup: Map the Engagement stream to an appropriate DMO. If not already set, go to that DMO’s Relationship page and relate it to Individual or Account.
- The relationship must Many:1 or 1:1 cardinality to the Individual ID or Account ID field.
- Create a Related List Enrichment: go to the Object Manager page of the CRM Object and go to the Related List tab. Hit “New”, go through the flow, and Save. This creates a new lookup to the DMO, which can be added to a Record Home as either a Standard Related List or a Dynamic Related List (recommended).
Now let’s walk through a few use-cases of increasing complexity, breaking down how the list generation process plays out.
Use Case 1: Email Engagement DMO
Say the Admin ingested some Contacts from a Salesforce org into the Individual DMO, and they’ve ingested some Emails from Amazon S3 into the Email Engagement DMO. Now they want to list all emails ever sent to each Contact on their Contact Record Home.
- The Email Engagements have a field linking them to Individual IDs.
- The Admin runs Identity Resolution on the Individual DMO, which generates a Unified Individual DMO and a Unified Link Individual DMO (which maps Unified Individual IDs to Individual IDs).
With that setup, the Admin creates a new Related List on Contact. They select the Email Engagement DMO as their Data Cloud Object and the Unified Individual DMO they want to use. They then add the created lookup to a Dynamic Related List on the Contact Record Home Page Layout.
Now, say a Service Rep opens Bill James’ Contact Record Home in Service Cloud.
- The Dynamic Related List will look for any Individual DMO record where Bill James’ Contact ID = Individual ID.
- It will query the corresponding Unified Individual ID, then query all Individuals related to that Unified Individual.
- It will then query all Email Engagement DMO records related to each Individual and show them on Bill James’ Related List.
- So, if Bill James got 2 emails, William James got 1, and their profiles were unified, Bill’s RL would have 3 emails.
Before, a Service Rep would have to look at both Record Homes to see all his emails. Now with Data Cloud, Bill and William were recognized as the same person (just with two records), and a Service Rep could reference all prior correspondence with one Related List Enrichment.
Use Case 2: Email Engagement DMO
Say the Admin ingests some Contacts from Salesforce Org A and some from Salesforce Org B. They also ingest Email Engagements from Amazon S3, but these only match Contacts from Org B. Despite this, the Admin wants to make a Related List of Email Engagements on Org A.
This is still possible, as the Related List queries via the Unified Individual. If an Org A record is unified with an Org B record, the Org A Record Home will list the same Email Engagements as the Org B Record Home.
For example, say Bill James is a Contact from Org A, and William James is a Contact from Org B.
- Both get mapped into the same Individual DMO in the same Data Space.
- They are unified together via Identity Resolution.
- The Dynamic RL will find Bill James’ Unified Individual, find that William James is related to the same Unified Individual, and list all William’s emails on Bill’s Contact Record Home.
Thanks to Identity Resolution from Data Cloud, Related List Enrichments were able to show Service Reps in Org A all of Bill’s relevant emails, no matter what Data Source they originated from.
Final Remarks
Hopefully, now you have a better picture of how Copy Fields and Related work. Instead of leaving data trapped in a warehouse, Data Cloud lets you get data into end users’ hands, seamlessly integrated into your business processes.
Want to see Data Cloud Enrichments in action? Check out the demos shown in this LinkedIn webinar!
Stefan Quaadgras, thank you for the walkthrough of the data cloud enrichments. In the demo, I noticed that for Related List Enrichments, you had the contact’s SF Id stored in your external system (Amazon S3) for Email Engagements DMO. This seems to make it easier to create an N:1 relationship between the Email Engagements DMO and Individual DMO.
However, in our company, we do not store SF ids in external systems; instead, we store contact email addresses. Because of this, I am having difficulty creating an N:1 relationship between the Email Engagements DMO and the Individual/Unified Individual DMO, and thus, I am unable to create a related list for Engagement DMO on the contact.
Could you please advise on the best way to use the email address in the Engagement DMO (coming from the external system through Data Streams) as an identifier to display all engagement records associated with a particular email address on the respective contact’s record page?
Many Thanks