Five Misconceptions About Data Cloud
Data Cloud was one of the most widely discussed topic at this year’s Dreamforce. It is going to be the engine that will power the AI + Data + CRM revolution and lay foundation for numerous upcoming AI & CRM initiatives. It’s clear that the Salesforce architects community will need to guide customers as they adopt this new technology. To do this well, architects will need a base level of knowledge of what the Data Cloud product is designed to do and what architectural patterns to avoid. Let’s take a look at five misconceptions that stump Salesforce architects who are new to Data Cloud.
Misconception #1: You need a new org for Data Cloud
Let’s start with a common confusion: which Salesforce org should the Data Cloud application reside in? There is no restriction on which org can be selected to set up Data Cloud. You don’t need a new org, you can leverage an existing instance in your landscape to be the “home” org for Data Cloud. If you only have one Salesforce org, the answer is easy. Leverage your single org for Data Cloud. But what if you have multiple Salesforce orgs in your landscape? To answer this question you’ll need to evaluate two conditions: data residency and desired data control.
If there are residency requirements that mandate the data to reside in specific regions then it is best to have one Data Cloud instance per region as shown below.
If there aren’t data residency restrictions and there is a need for centralized control over Data Cloud activities, then having one instance makes sense. In this scenario, you’ll want to designate a home org to setup Data Cloud in. This will provide centralized control for the data across your Salesforce landscape.
Misconception #2: Data harmonization can be done by technical teams alone
Data Harmonization is the process of mapping the ingested data from different data sources to a common data model. While the mechanics of mapping will be done by a technical user in Data Cloud, the decision-making process for what gets mapped where involves stakeholder management and governance. Harmonization can become quite challenging and intensive when different orgs have same standard or custom fields used for different purposes.
As part of data harmonization it is important to carry out detailed data analysis with business and IT to identify these challenges and address them in the common model in Data Cloud. Here are some of the challenges that can crop up while creating a harmonized data model:
- Data model definitions — Lack of documented data definitions can lead to multiple custom objects or fields getting created in Data Cloud for same type of data.
- Understanding of transformation requirements — Data transformation is important to ensure that standardized values exist in Data Cloud. It can be challenging to get common transformation rules across orgs and it can lead to redundant data values or data values that cannot be interpreted correctly by users across orgs post harmonization.
- Relationship Mapping — In case of multiple orgs, it is possible that data model for similar data can be designed differently. For example, if there are multiple accounts associated with an opportunity. One org can have custom lookups for these account relationships while other can have a junction object. Understanding these nuances of the relationship and mapping them to a common model can be challenging and requires careful data modeling in Data Cloud.
Also, different data models in different orgs require careful evaluation of each object and their fields for mapping with the common model. Architects should pay special attention to the business purpose of each standard and custom object in each individual orgs to arrive at a universal data model.
Misconception #3: Data Cloud is a master data management (MDM) solution
Data Cloud is not a Master Data Management (MDM) tool. As such, Data Cloud does not provide a Universal CustomerID for use across systems or multiple Salesforce orgs.
Data Cloud is a tool that allows you to get a complete view of your customer’s data. With Data Cloud you can create a Unified Profile for your customer using matching and reconciliation rules. Let’s take a closer look at these two tools:
- Matching Rules — Determine which records are considered “the same”. Identifying common profile matching rules for data across orgs can be a challenge. Every org can have different attributes for identifying uniqueness and inclusion of all possible combinations is very important while designing matching rules in Data Cloud.
- Reconciliation Rules- Determine which record should “win” on the Unified Profile when there are conflicting data points. While defining reconciliation rules in Data Cloud architects should not just consider the recency of the record updates in the source orgs but should pay special attention to the trust level of the source for each and every attribute.
Misconception #4: Data Cloud automatically propagates information to other systems
A common misconception is that Data Cloud automatically propagates the Unified Profile data back to the source systems or Salesforce org. Data Cloud provides a unified view of the customer’s data from different touch points. This single view of the customer is meant to be used as a source for building valuable use cases like:
- Creating & activating marketing segments
- Building AI models
- Publishing insights
- Creating analytics dashboards
- Crafting business processes that respond to triggers from Data Cloud
The Data Cloud Unified Profile is not intended to provide a golden copy of the customer’s record that should be synced back to all the sources systems for maintaining a local copy in the way that an MDM or ESB would.
The following flow provides an overview of how data from source systems is unified in Data Cloud and what it’s designed to do post-unification:
That said, Data Actions can be used to create platform events if you want to send specific information to downstream orgs, and as of Winter ’24 you can enrich your CRM contacts and leads using a new capability called Data Enrichments.
Misconception #5: Data Actions can be designed in Data Cloud without configuring the target org
Data Actions can create platform events targeted to specific orgs that can in turn trigger flows to carry out specific business process and actions. But Data Action design involves more than just Data Cloud. It is very important to have a thoughtful design for the target org that will be consuming the Data Actions and triggering the appropriate processes.
When multiple events are firing it becomes critical to design the flows that trigger the right processes based on the order of events in your business process. Architects can consider designing a wrapper flow that consumes the Data Actions and then routes the data to the appropriate sub flow. Alternatively, appropriate decisioning can be added in the flows to route the data actions to an appropriate branch and ensure that the right process gets triggered from Data Actions.
You can get deeper insights on how to design data actions & flows for multi-cloud architecture in this post by William Yeh.
Conclusion
Clear understanding of Data Cloud capabilities and a carefully crafted architecture are key to successful Data Cloud implementations. Getting alignment with your customers should be the first priority for architects. A great way to do this is by getting hands-on with the product. Encourage your customers to leverage free Data Cloud licenses to understand the challenges associated with customer data and uncover issues by carrying out a proof of concept first. These initial learnings will lay the foundation for a scalable enterprise-wide data strategy using Data Cloud.
Resources
Data Cloud Architect Template Gallery
Trailhead: Get Started with Data Cloud
Trailhead: Build a Data Strategy for Data Cloud
Trailhead: Ingestion & Modeling in Data Cloud
Trailhead: Customer 360 Data Model for Data Cloud
Trailhead: Data and Identity in Data Cloud
Data Cloud Help Documentation
Data Cloud Developer Center
Data Cloud Guides
FAQs: Free Data Cloud Account
