Salesforce Multi-Cloud Architecture
How to combine several Salesforce clouds with external platforms such as Braze and an ERP, share identity, coordinate releases and choose an org strategy.
A Salesforce multi-cloud architecture combines several Salesforce products, such as Sales Cloud, Service Cloud, Marketing Cloud, Commerce Cloud and Data 360, with external platforms such as Braze or an ERP. Some of these run in your core Salesforce org; others are separate tenants with their own users, APIs and release schedules. This page covers how to connect them, share identity, coordinate releases and choose between one org and several. It is a reference design; we validate the APIs, edition and permissions for each implementation.
Business context
Multi-cloud estates grow by addition. A business buys Marketing Cloud Engagement for email, B2C Commerce for the storefront, Data 360 for a unified profile, and keeps an ERP for finance. Each product made sense alone; together they raise new questions. Which identifier links a shopper to a contact? Which team approves a change that touches three clouds? What happens when one platform's release changes behaviour the others rely on?
It helps to separate three kinds of component:
- Core-platform products that share one org's data model, users and metadata: Sales Cloud, Service Cloud, Marketing Cloud Next and Data 360.
- Separate Salesforce tenants with their own administration: Marketing Cloud Engagement and B2C Commerce.
- External platforms from other companies, such as Braze or an ERP. Salesforce has announced an agreement to acquire Braze, but the deal is pending, subject to shareholder and regulatory approval and expected to close in Salesforce's fiscal 2028. Until then they are separate companies, and Braze's customer materials say post-close plans are "possibilities, and no decisions have been made yet."
GeekMidst can design and implement multi-cloud architectures, including Salesforce and Braze integration. See Salesforce architecture consulting.
Salesforce multi-cloud reference architecture
Reference architecture: a reusable pattern, not a live client integration
Select a component to see what it is responsible for and how data moves to and from it.
Components and data flows (text version)
| Component | Type | Responsibility |
|---|---|---|
| Sales and Service Cloudcore org | Salesforce product | System of record for accounts, contacts, opportunities and cases. Shares metadata, users and the data model with other core-platform products. |
| Marketing Cloud Nexton the core platform | Salesforce product | Agentic marketing built on the Salesforce Platform with Data 360. Complements Marketing Cloud Engagement rather than replacing it, per Salesforce. |
| Data 360unified profile | Data and analytics | Unifies identity across clouds and external sources, builds segments and calculated insights, and activates them. |
| Marketing Cloud Connectmanaged package | Integration layer | Syncs chosen CRM objects to Marketing Cloud Engagement and writes tracking data back to CRM. Needs a supported CRM edition and both licences. |
| Integration layerMuleSoft or other iPaaS | Integration layer | Connects the core org and external platforms with transformation, retries, logging and a dead-letter queue. |
| Identity key mapsource IDs to shared IDs | Data and analytics | Maps CRM IDs, commerce customer numbers and external platform IDs, such as Braze external_id, to each other. |
| Marketing Cloud Engagementseparate tenant | Salesforce product | High-volume email, SMS and journeys. Its own users, business units and deployment process. |
| B2C Commerceseparate tenant | Salesforce product | Storefront, baskets and orders, administered in Business Manager with its own release cycle. |
| Brazeexternal company | External or custom system | Customer engagement platform with its own profiles, events and subscription states. Integrated through its REST APIs and data exports. |
| ERPexternal | External or custom system | Owns invoices, payments and stock. Integrated only through the integration layer. |
Data flows
- Sales and Service Cloud → Marketing Cloud Connect: selected objects. Synchronised data sources poll CRM objects at an interval you set. Every synced contact or lead counts as a contact in Contact Builder.
- Marketing Cloud Connect → Marketing Cloud Engagement: sync and sends. Synchronised data extensions and CRM-driven sends. A paused sync leaves audiences stale; monitor it.
- Sales and Service Cloud → Integration layer: record events. Change Data Capture or platform events tell the integration layer about changes without polling.
- Data 360 → Identity key map: unified IDs. Unified Individuals and link objects inform the key map; source IDs remain the keys used for write-backs.
- Data 360 → Marketing Cloud Next: segments and consent. Marketing Cloud Next runs on Data 360: it uses published segments and checks consent DMOs at send time.
- Identity key map → Integration layer: ID lookups. The integration layer translates identifiers before calling an external platform.
- Integration layer → Braze: profiles, events, consent. Calls Braze /users/track and subscription endpoints within documented rate limits; failures retry, then dead-letter.
- Integration layer → ERP: orders and accounts. Validated messages to the ERP, idempotent so retries do not create duplicates.
- ERP → Integration layer: invoices and stock. Reference data back to CRM as read-only fields.
- Braze → Integration layer: engagement and opt-outs. Currents event streams to storage or the Custom HTTP Connector; middleware applies opt-outs and summaries.
- Marketing Cloud Engagement → Data 360: connector and activation. The Engagement connector brings engagement data into Data 360; segments are activated back to Engagement.
- B2C Commerce → Data 360: commerce data. B2C Commerce has a Data 360 connector for shopper and order data.
Org strategy: single org or several
| Factor | Single org | Multiple orgs |
|---|---|---|
| Shared customer view | Native: one data model and sharing model | Needs integration or Data 360 to join the orgs |
| Autonomy of business units | Lower; shared release train and governance | Higher; each org releases on its own plan |
| Regulatory or regional separation | Needs careful sharing and encryption design | Cleaner separation, with more to operate |
| Cost of change | One place to change, but more people affected | Changes are local, but cross-org features cost more |
| Limits and performance | All volume in one org's limits | Volume spread across orgs |
| Cross-org data sharing | Not needed | Salesforce to Salesforce retires in Spring '27, so plan integration or Salesforce Connect instead |
Start from one org unless there is a clear reason to split, such as legal separation, very different business models, or independent subsidiaries. Splitting later is expensive; merging later is harder still.
Data flow, step by step
- A contact is created in Sales Cloud. Marketing Cloud Connect syncs it to Engagement on the next polling interval.
- The same change reaches Data 360 through the CRM connector and the integration layer through Change Data Capture.
- Data 360 links the contact to a B2C Commerce shopper through identity resolution, and the key map records the IDs.
- The integration layer looks up the Braze external_id and updates the Braze profile and subscription state.
- Engagement and Braze send messages; engagement and opt-outs flow back to Data 360 and the consent store.
Trust boundaries and authentication
Each tenant has its own identity and admin model: the core org, Marketing Cloud Engagement, B2C Commerce, Braze and the ERP. Use a dedicated integration user or API key per connection, with least privilege, stored server-side. For the core org, build new integrations on External Client Apps, since Salesforce has said connected apps support ends in Summer '27. Braze REST API keys are scoped per endpoint and cannot be edited after creation. Note that Braze's documented Salesforce Sales Cloud integration is community-submitted, not directly supported by Braze, and one-way to the Lead object, so production designs normally need middleware or custom code.
Failure scenarios and how to handle them
| Scenario | Effect | Handling |
|---|---|---|
| One platform's release changes behaviour | Broken journeys or syncs | Regression tests in sandboxes during each preview window |
| Identifier mismatch between platforms | Messages to the wrong profile or duplicates | Key map with validation; never use email as the Braze external_id |
| Integration layer outage | Changes queue up | Durable queues, replay from stored positions, reconciliation reports |
| Conflicting changes across tenants | Data flip-flops | One writer per field, documented in the ownership matrix |
| Rate limits at an external API | Delayed updates | Batch requests and respect documented limits |
Release coordination and monitoring
Salesforce releases three times a year. For Winter '27, sandbox preview began on 28 August 2026 and production upgrades ran on 4 September, 2 October and 9 October 2026 by instance; check trust.salesforce.com for your instance. Braze and Marketing Cloud Engagement release on their own schedules, so keep one cross-platform release calendar and run regression tests in every preview window. Monitor integration error rates, sync lag, dead-letter depth and identity match rates on one dashboard. Our CI/CD and release management architecture covers the pipeline.
Alternative approaches and trade-offs
- Point-to-point connectors are quick for two platforms and brittle at five.
- Data 360 as the hub reduces custom identity work across Salesforce products, but external platforms such as Braze still need integration; we found no Braze-documented Data 360 integration.
- Consolidating onto fewer platforms simplifies operations but is a programme in itself. Compare options in Salesforce vs Braze.
Implementation checklist
- 01
Inventory platforms
List every cloud, tenant and external platform, with owner and release schedule.
- 02
Decide the org strategy
Single or multiple orgs, with the reasons written down.
- 03
Write the ownership matrix
One system of record per entity and field.
- 04
Design shared identity
Agree identifiers and build the key map.
- 05
Build the integration layer
Retries, logging, dead-letter queue and monitoring.
- 06
Set up release governance
A shared calendar, change board and regression packs.
- 07
Rehearse a release
Run a full cross-platform release in sandboxes first.
Related services and solutions
Salesforce and Braze architecture
How the two platforms connect
→Salesforce and Braze integration
Integration service
→Customer 360 architecture
Systems of record and unified profile
→Integration solutions
Patterns for connecting Salesforce
→Programme governance
Running growing Salesforce programmes
→Architecture consulting
Org strategy and target-state design
→Questions we hear
Should we run one Salesforce org or several?
Will Braze become part of Marketing Cloud?
Can Data 360 connect several orgs?
Who should own releases across clouds?
Sources
- https://www.salesforce.com/products/
- https://trailhead.salesforce.com/content/learn/modules/marketing-cloud-connect/get-started-with-mc-connect
- https://www.sec.gov/Archives/edgar/data/0001108524/000119312526425881/d516983dex991.htm
- https://www.sec.gov/Archives/edgar/data/0001676238/000095010326015917/dp255270_defa14a.htm
- https://www.braze.com/docs/user_guide/get_started/b2b_use_cases/b2b_salesforce_sales_cloud
- https://admin.salesforce.com/blog/2026/admin-winter-27-release-countdown
Bring your clouds into one design
We can review your org strategy, design shared identity and integration, and plan releases across platforms. Consultations are remote, from India.
