Data 360 reference architecture
How data moves through Data 360, from sources and data streams to unified profiles, insights, segments and activation, plus an integration path to Braze through middleware.
Data 360 (formerly Data Cloud) is Salesforce's data layer for CRM, analytics and AI agents. It brings data in from Salesforce and other sources, harmonises it, resolves identities into unified profiles, and makes segments and insights available to other systems. Most of the effort in an implementation goes into the middle layers: mapping, identity rules and refresh schedules. This page gives a reference architecture for the full path, from sources to activation, and links to our Data 360 architecture guide for depth.
This is a reference design. We validate the licences, connectors, APIs and permissions for each implementation, and GeekMidst can design and implement it through Data 360 consulting.
Business context
Teams usually adopt Data 360 for one of three reasons: a single customer profile across CRM, commerce and marketing; audiences that update without nightly exports; or grounding AI agents in governed customer data. Each goal puts weight on a different layer. Profiles depend on identity rules; fresh audiences depend on refresh modes and the real-time layer; agent grounding depends on governance and data quality.
Data 360 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 |
|---|---|---|
| Salesforce CRMSales, Service, Industries | Salesforce product | CRM objects ingested through Salesforce's CRM connectors. |
| Marketing Cloud Engagementdata extensions, engagement | Engagement platform | Engagement and subscriber data ingested through the Marketing Cloud Engagement connector. |
| Web and mobileInteractions SDK | Channel or touchpoint | Behavioural events from websites and apps. The SDK sends events only after consent. |
| Data warehousesSnowflake, Databricks, BigQuery | External or custom system | Warehouse tables queried through zero copy federation or ingested. |
| Files and APIsCSV, Ingestion API | External or custom system | Batch files and Ingestion API calls from other systems. Ingestion API data can take up to an hour to appear. |
| Data streamsProfile, Engagement, Other | Integration layer | Each stream has a category, a primary key and, for Engagement, an event time. Refresh mode cannot be changed after creation. |
| Zero copy federationquery without copying | Data and analytics | Query federation and live query read warehouse data in place; file federation is labelled beta on Salesforce's page. |
| Data lake objectsDLOs | Data and analytics | Containers for ingested data, close to source shape. |
| Data transformsbatch or streaming | Data and analytics | Batch transforms run on a schedule; streaming transforms run continuously in SQL. Input and output can be DLOs or DMOs. |
| Data model objectsCustomer 360 Data Model | Data and analytics | Harmonised objects mapped from DLOs. Starter data bundles can auto-map some sources. |
| Identity resolutionmatch and reconciliation rules | Data and analytics | Exact, fuzzy and normalised match rules, and reconciliation by most frequent, most recent or source priority. |
| Unified profilesUnified Individual | Data and analytics | Output of identity resolution, with unified link objects and contact points. Source data is not altered. |
| Calculated insightsmetrics such as LTV | Data and analytics | Metrics at profile, segment or population level, queryable through Data 360 and Connect REST APIs. |
| SegmentsSegment On Unified Individual | Data and analytics | Audiences built on an entity and published on a schedule or with Publish Now. |
| Activationssegment plus target | Integration layer | Link a segment to an activation target with direct and related attributes. Results land in an Audience DMO. |
| Data actionsPlatform Events, webhook | Integration layer | Triggered by insights or data changes, sending to Platform Events, Marketing Cloud or a webhook. |
| Governanceconsent, access, policies | Identity, policy and governance | Consent records, permissions and Data 360 governance controls over who and what can use each data set. |
| Salesforce apps and agentsFlow, Apex, Agentforce | Salesforce product | Platform Events and Flow act on data actions; Agentforce agents ground answers in Data 360. |
| Marketing CloudEngagement or Next | Engagement platform | Receives activated segments and decisions for journeys and sends. |
| Integration layermiddleware or iPaaS | Integration layer | Receives webhooks or reads shared data, maps it and calls non-Salesforce APIs with retries and an error queue. |
| Warehouse sharedata shared out | Data and analytics | Bi-directional data sharing makes Data 360 data available in your warehouse for other tools. |
| Brazevia API or Cloud Data Ingestion | Engagement platform | Receives attributes and events through the /users/track API or Cloud Data Ingestion from a supported warehouse. No native Data 360 connector is documented. |
Data flows
- Salesforce CRM → Data streams: CRM connector. Selected objects are ingested on the stream's refresh schedule. Failures show in data stream status.
- Marketing Cloud Engagement → Data streams: MCE connector. Engagement and subscriber data are ingested from the Marketing Cloud Engagement account.
- Web and mobile → Data streams: consented events. Standard web streams load engagement every 15 minutes and profiles hourly; the real-time layer is much faster.
- Data warehouses → Zero copy federation: federated query. Data stays in the warehouse; queries depend on warehouse availability and performance.
- Files and APIs → Data streams: batch and API. Files and Ingestion API payloads. Bad rows are rejected; check stream status and row counts after each load.
- Data streams → Data lake objects: ingested rows. Rows land in DLOs keyed by the stream's primary key.
- Data lake objects → Data transforms: transform input. Transforms clean, join or reshape data before mapping.
- Data transforms → Data model objects: mapped output. Transform output is written to DMOs used by identity and segments.
- Zero copy federation → Data model objects: zero copy DMOs. Federated tables are mapped to DMOs like ingested data.
- Data model objects → Identity resolution: profile DMOs. Identity resolution reads individual and contact point DMOs. Bad source data produces bad merges.
- Identity resolution → Unified profiles: unified individuals. Rulesets produce Unified Individuals. Runs can be scheduled to control cost.
- Unified profiles → Calculated insights: profile metrics. Calculated insights aggregate engagement and transactions per profile.
- Unified profiles → Segments: segment base. Segments are built on Unified Individuals and their related data.
- Calculated insights → Data actions: insight triggers. A change in an insight can fire a data action.
- Segments → Activations: published segments. Each publish refreshes the activation. Monitor publish duration and member counts.
- Activations → Marketing Cloud: Marketing Cloud activation. Segments activate to Marketing Cloud targets for journeys and sends.
- Data actions → Salesforce apps and agents: Platform Events. Data actions publish Platform Events that Flow or Apex can act on.
- Data actions → Integration layer: webhook. Data actions call a webhook in the integration layer, which queues the payload and acknowledges quickly.
- Segments → Warehouse share: data sharing out. Bi-directional data sharing exposes selected Data 360 data, such as segments or insights, to your warehouse.
- Integration layer → Braze: /users/track. Middleware maps attributes to Braze profiles by external_id and respects Braze rate limits; failures go to an error queue.
- Warehouse share → Braze: Cloud Data Ingestion. Braze CDI reads a sync table or view you prepare in Snowflake, BigQuery, Databricks, Redshift or Microsoft Fabric. Syncs can run as often as every 5 minutes (dashboard default minimum 15).
Component responsibilities
| Component | Responsible for | Design note |
|---|---|---|
| Data streams | Bringing source data in | Choose refresh mode carefully; it cannot be changed later |
| Zero copy federation | Using warehouse data without copying it | Depends on warehouse availability; file federation is labelled beta |
| DLOs | Holding ingested data | Keep close to source shape |
| Data transforms | Cleaning and reshaping | Batch for heavy work, streaming for continuous updates |
| DMOs | Harmonised model for downstream use | Map to the Customer 360 Data Model |
| Identity resolution | Linking records to one person | Test match rules before go-live |
| Calculated insights | Metrics such as LTV | Can trigger data actions |
| Segments and activations | Audiences for other systems | Results land in an Audience DMO |
| Data actions | Event-driven outputs | Platform Events, Marketing Cloud or a webhook |
| Governance | Consent, permissions and policies | Decide who can use which data before agents and marketers do |
Data flow, step by step
- Connect sources. CRM sources use Salesforce's CRM connectors; files, APIs and SDK events use their own streams; warehouse tables can be federated with zero copy. See choosing data stream ingestion patterns.
- Land and transform. Data arrives in DLOs. Batch or streaming transforms clean and reshape it; the trade-offs are in batch vs streaming transforms.
- Map to DMOs. DLOs are mapped to the Customer 360 Data Model.
- Resolve identity. Match and reconciliation rules create Unified Individuals; read how match rules work.
- Compute insights and segments. Calculated insights produce metrics; segments are published on a schedule or on demand.
- Activate. Activations send segments to Marketing Cloud; data actions publish Platform Events or call webhooks.
- Reach Braze through the integration layer. No native Braze connector is documented, so middleware calls the Braze API, or Braze Cloud Data Ingestion reads data shared to your warehouse.
Real-time paths
Under the Sub-Second Real-Time Profile, Salesforce documents that 95% of events complete ingestion to activation within about 500 milliseconds, from the Web SDK, Mobile SDK or server-to-server ingestion. Real-time data graphs are required for real-time identity resolution, insights, segments and data actions. Standard streams are slower, so latency depends on the sources and features you choose.
Trust boundaries and authentication
Data 360 runs inside your Salesforce trust boundary, with access set by permissions. Webhook targets and middleware sit outside it: authenticate them, sign or verify payloads, and keep secrets server-side. Braze is a separate company's platform with its own API keys, scoped per endpoint. AI access is a further boundary: the Data 360 MCP Server is GA (per Salesforce, 19 August 2026), and its hosted server supports read and write tools with OAuth and counts toward Connect API limits and Flex Credits, so start with read-only access.
Failure scenarios and how to handle them
| Failure | Effect | How to handle it |
|---|---|---|
| Source refresh fails | Stale profiles and segments | Alert on stream status; block activation if data is too old |
| Wrong refresh mode chosen | Rebuild needed | Decide refresh mode in design; it cannot be changed later |
| Match rules over-merge | Two people share one profile | Test on samples; prefer stricter rules first |
| Segment publish slow | Late campaigns | Monitor publish times; schedule sends after publish |
| Webhook target down | Missed events | Queue in middleware; retry with idempotency keys |
| Braze rate limit reached | 429 responses | Back off using Braze rate-limit headers; batch requests |
Operational monitoring
Track data stream refresh status and row counts, identity resolution run results and unified profile counts, segment publish duration and member counts, activation status, and middleware queue depth and error rates. Our Data Cloud monitoring guide lists what to check.
Alternative approaches and trade-offs
Ingest versus zero copy: ingesting gives Data 360 full control of refresh and transforms; zero copy avoids duplication but depends on the warehouse. Warehouse-first activation to Braze (data sharing plus Braze CDI) avoids custom API code but adds sync delay; API activation through middleware is faster but needs rate-limit handling. A separate CDP may suit estates where Salesforce is not the centre; see Data 360 vs customer data platforms.
Implementation checklist
- 01
Confirm licences
Data 360 provisioning, credits and any connector or feature add-ons
- 02
Inventory sources
Owners, keys, volumes and freshness needs per source
- 03
Choose refresh modes
Decide before creating streams
- 04
Design the model
DLO to DMO mapping and transforms
- 05
Define identity rules
Match and reconciliation rules, tested on sample data
- 06
Design governance and consent
Who can use which data, and how consent is recorded
- 07
Plan activation
Marketing Cloud targets, data actions and the Braze path
- 08
Monitor
Refreshes, identity runs, publishes and middleware errors
Related services and solutions
Data 360 architecture guide
The long-form guide
→Data 360 consulting
Design and implementation
→Identity resolution
Match and reconciliation rules
→Data 360 and Braze
Solution design for activation to Braze
→Salesforce and Braze architecture
The wider integration
→Marketing Cloud Next architecture
Marketing on Data 360
→Questions we hear
Is this a client architecture?
Can Data 360 activate directly to Braze?
Is Data 360 real time?
Can AI agents use Data 360 data?
Sources
- https://www.salesforce.com/data/
- https://developer.salesforce.com/docs/data/data-cloud-dev/guide/dc-object-model.html
- https://trailhead.salesforce.com/content/learn/projects/explore-data-cloud-core-functionality/unify-your-data
- https://developer.salesforce.com/docs/data/data-cloud-ref/guide/c360a-real-time-ingestion-api.htm
- https://www.salesforce.com/data/connectivity/zero-copy/
- https://www.braze.com/docs/user_guide/data/cloud_ingestion
Plan your Data 360 architecture
Tell us about your sources and what you want to activate. We can propose a Data 360 design, including the integration path to non-Salesforce platforms.
