← All posts
· 4 min read ·
SalesforceArchitectureCommerce CloudIntegration

Multi-Cloud Salesforce Architecture: Making the Clouds Actually Talk

Lessons from designing and implementing multi-cloud Salesforce environments - Commerce Cloud, Sales Cloud, Service Cloud, Marketing Cloud - that work as a coherent system.

Global network visualization representing cloud architecture

Running a single Salesforce cloud is a solved problem. Running four of them in a coordinated way - Commerce Cloud, Sales Cloud, Service Cloud, Marketing Cloud - as a coherent system is a different challenge entirely.

The Core Problem: Data Sovereignty

Every Salesforce cloud has its own data model and its own version of “the customer”. Commerce Cloud has a customer profile. Marketing Cloud has a contact and subscriber. Sales Cloud has an Account and Contact. Service Cloud has a Case contact.

These aren’t the same record. They need to be.

The solution isn’t to pick one as the master and sync everything to it - it’s to establish a Customer Identity Resolution layer. In practice, this means:

  • Salesforce Data Cloud (formerly CDP) as the unified identity graph
  • A canonical External_Customer_ID__c field on every object in every cloud, populated at creation
  • Event-driven sync rather than batch - changes propagate in near real-time via Platform Events

Commerce Cloud ↔ Sales Cloud

The most common integration pattern is order data flowing from SFCC to Sales Cloud for account management. The trap is treating this as a one-way sync.

It’s bidirectional. Sales teams need to see order history. Commerce needs to know account status (is this customer on credit hold?). Service needs case context when a customer contacts support about an order.

A canonical order object in Sales Cloud as the integration anchor - SFCC writes to it via REST, Service Cloud reads from it, and triggers handle downstream propagation.

SFCC → REST API → Order__c (Sales Cloud)
                      ↓ (Platform Event)
              Case enrichment (Service Cloud)
                      ↓ (Marketing Cloud Connect)
              Journey entry (Marketing Cloud)

Marketing Cloud Connect is straightforward to set up and endlessly complicated in production. The real difficulty is consent management at scale.

GDPR and CCPA mean you need a consent record that is the source of truth for all clouds. We build this in Sales Cloud with a custom Consent__c object, and every cloud queries it before any communication action. Marketing Cloud’s native subscription management is a convenience layer on top of that, not the system of record.

Service Cloud: The Last Mile

Service Cloud usually gets integrated last and suffers for it. Agents end up with six browser tabs open because the context from the other clouds hasn’t been surfaced properly.

Build a single 360 Customer Console component in Service Cloud that pulls:

  • Active orders from Commerce Cloud (live, not synced data)
  • Campaign membership and engagement from Marketing Cloud
  • Account health and opportunity pipeline from Sales Cloud

One component, one query fan-out. Agents go from tabs to context.

Platform Events as the Integration Backbone

Batch jobs between clouds are an anti-pattern for a multi-cloud system. By the time the batch runs, the data is stale and you’ve created a race condition.

Platform Events give you near real-time integration with built-in replay capability. Every significant business event - order placed, case resolved, consent changed - fires a Platform Event that all subscribing clouds react to independently.

The pattern:

  1. Originating cloud publishes a Platform Event
  2. Each subscribing cloud has a trigger or flow that handles it idempotently
  3. Failures are logged and replayed, not silently dropped

The idempotency is crucial. In a multi-cloud system with retry logic, you will receive the same event more than once. Build for it.

What Goes Wrong

The three failure modes I see most often:

Governor limit cascades - an event handler in one cloud triggers actions in three others, each of which fires its own events. Map your event chains before you build them.

Schema drift - Sales Cloud’s API version is updated, a field changes, and Commerce Cloud’s integration breaks silently. Enforce API version contracts and test cross-cloud integrations in CI.

Circular updates - Cloud A updates a record, fires an event to Cloud B, Cloud B updates and fires back to Cloud A, repeat forever. Every event handler must check whether the update was triggered externally before firing its own events.

Multi-cloud Salesforce is genuinely complex - but it’s manageable complexity if you invest in the integration layer as a first-class product, not an afterthought.

← All posts