Home / architect / cross-cloud-data-deployment

cross-cloud-data-deployment

Cross-cloud data deployment: designing the data handoff when an implementation spans Sales Cloud, Service Cloud, Marketing Cloud, Data Cloud, Commerce Cloud. Shared keys, identity resolution, sync vs event, CDC, Data Cloud as hub. NOT for configuring the Data Cloud identity-resolution ruleset itself — use admin/data-cloud-identity-resolution. NOT for designing Data Cloud DMOs and their relationships — use data/data-cloud-data-model-objects. NOT for integration pattern selection — use the integration-pattern-selection decision tree.

v1.0.0
Salesforce Spring '25+
Updated 2026-04-21
Scalability
Reliability
Security

cross-cloud
data-cloud
identity-resolution
cdc
marketing-cloud
data-model
deployment

Open the skill folder on GitHub

Cross-Cloud Data Deployment

Activate when an implementation spans multiple Salesforce clouds (Sales, Service, Marketing, Commerce, Data Cloud, Industries) and data must be consistent across them. Cross-cloud is less about "how do we integrate?" and more about "who owns which field, and how does the truth propagate?"

Before Starting

Identify the system of record per entity. Customer in Sales Cloud or Data Cloud? Product in Commerce or PIM? Case in Service or Industries? Write it down. Ambiguity here breaks everything downstream.
Draw the flows BEFORE picking tech. A whiteboard diagram of data flowing between clouds is the artifact that drives integration selection, not the other way around.
Establish the shared key strategy early. External IDs, Person IDs, Account IDs — whichever key ties clouds together must be chosen before data model finalization.

Core Concepts

Data Cloud as the hub

Data Cloud ingests from Sales / Service / Commerce / Marketing, performs identity resolution, builds a unified profile, and exposes back via Calculated Insights, Activations, and Zero Copy. It becomes the cross-cloud customer brain.

Identity resolution

Matching rules (deterministic or probabilistic) collapse multiple Contact / Lead / Customer records across clouds into a Unified Individual. The rule set is per-org and evolves.

Change Data Capture (CDC) vs Platform Events

CDC emits record-level field changes automatically; Platform Events are bespoke business events. For cross-cloud sync of CRUD, prefer CDC; for domain events (Order Shipped, Case Escalated), prefer Platform Events.

Shared keys

External ID fields on each cloud point to a common reference. Pattern: every record carries the same Global_Customer_Id__c with External ID + Unique. Upserts become trivially safe.

Common Patterns

Pattern: Sales + Service co-resident; Marketing via Data Cloud

Sales and Service share one org (one Account, Contact). Data Cloud ingests from the org and from Marketing Cloud; Marketing activates segments back. Clean.

Pattern: Sales + Commerce with Order propagation

Commerce creates Orders; OMS / Sales Cloud handles service. Use Platform Events for "Order Placed" rather than REST sync — decouples cadence.

Pattern: Data Cloud Zero Copy for analytics, not operational

Zero Copy (Snowflake, BigQuery, Databricks) for analytics without duplication. NOT for operational sync — latency and semantics differ.

Decision Guidance

Situation	Recommended Approach	Reason
Shared customer identity across 3+ clouds	Data Cloud as hub	Native identity resolution
Sales ↔ Service single-org	Native relationships, no integration	Same org
Marketing engagement → Sales	Marketing Cloud Connect or Data Cloud Activation	Supported paths
Commerce order → Service case	Platform Events	Decoupled cadence
Analytics across clouds	Data Cloud + Zero Copy	No duplication

Recommended Workflow

Inventory the clouds in scope and the shared entities each owns.
Assign system-of-record per entity; document ownership explicitly.
Select shared keys; add External ID + Unique fields on each cloud.
Decide sync vs event per flow; pick CDC, Platform Events, Marketing Cloud Connect, or Data Cloud.
Design identity resolution rules in Data Cloud; validate with a two-cloud sample.
Plan the deployment order: data model first (shared keys), then integration, then activation.
Build an end-to-end smoke test from creation in cloud-A to arrival in cloud-B.

Review Checklist

[ ] System-of-record documented for every shared entity
[ ] External ID + Unique present on every cross-cloud object
[ ] Sync vs event decision made per flow
[ ] Data Cloud identity resolution rules tested
[ ] Deployment ordering respects key dependencies
[ ] Error handling and replay designed for every flow
[ ] Cross-cloud reporting strategy addressed

Salesforce-Specific Gotchas

Marketing Cloud Connect has its own identity model (Subscriber Key). Mapping Subscriber Key to Data Cloud Unified Individual requires explicit rules.
Data Cloud is not real-time for all flows. Streaming ingestion + CI refresh can mean minutes of lag; do not architect operational flows around Data Cloud latency.
CDC has order guarantees per record but not across records. Cross-object consistency must come from a different mechanism.

Output Artifacts

Artifact	Description
Cross-cloud topology diagram	Clouds, flows, shared keys
System-of-record matrix	Entity × cloud with SoR marked
Shared key inventory	External IDs across clouds
Deployment ordering plan	Data model → integration → activation

architect/multi-cloud-architecture — multi-cloud org strategy
integration/integration-pattern-selection — mechanism choice
data/data-cloud-foundation — Data Cloud specifics