Customer 360 Architecture
How Salesforce clouds, Data 360, Agentforce, analytics and an integration layer fit together, and how to decide which system owns each piece of customer data.
A customer 360 architecture connects the Salesforce applications your teams already use, such as Sales Cloud, Service Cloud, Marketing Cloud and Commerce Cloud, with a unified profile in Data 360, AI agents in Agentforce, analytics, and an integration layer for everything outside Salesforce. The connectors are rarely the hard part. The hard part is agreeing which system owns each piece of data, so that every other system treats its copy as a reference rather than a second master. This page is a reference design; we validate the APIs, editions and permissions for each implementation.
Business context
Salesforce still uses "Customer 360" for its application and business-logic layer, and its AIforce architecture describes Data 360, Customer 360 and Agentforce as layers that work together. Most organisations reach a customer 360 view in stages: CRM first, then marketing, then commerce or service, each holding its own copy of the customer. The symptoms are familiar. A service agent cannot see an open order, a promotional email reaches someone with an open complaint, and two dashboards disagree on how many active customers there are.
A sound design answers three questions before any build starts:
- Which system is the record owner for each entity: account, contact, consent, order, case, product and invoice?
- How does each application get the data it needs, and how fresh must that data be?
- Where does the unified view live, and who may read it, including AI agents?
GeekMidst can design and implement this architecture, from org strategy to Data 360 identity rules and integration. If you are earlier in the journey, start with Salesforce architecture consulting.
Customer 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 |
|---|---|---|
| Sales and Service Cloudcore Salesforce org | Salesforce product | System of record for accounts, contacts, leads, opportunities and cases. Other systems read these records; they do not edit their own copies. |
| Commerce CloudB2C, B2B, Order Management | Salesforce product | Owns baskets, orders and shopper accounts. Order status is mastered here or in Order Management, depending on the design. |
| Marketing CloudEngagement or Next | Salesforce product | Owns sends, journeys and engagement events such as opens and clicks. Reads contacts, segments and consent from their owners. |
| ERP and financeexternal | External or custom system | Owns invoices, payments, credit status and stock. Reached only through the integration layer, never by direct point-to-point calls from every app. |
| Integration layerMuleSoft Anypoint or other iPaaS | Integration layer | Moves data between Salesforce and external systems with retries, logging and a dead-letter queue. Holds secrets server-side. |
| Data 360unified profile | Data and analytics | Ingests data streams, maps them to the Customer 360 Data Model, resolves identity into Unified Individuals and builds calculated insights and segments. Source data is not altered. |
| Agentforceagents and actions | AI and agents | Agents answer and act for employees and customers, grounded in CRM records and Data 360 context, under the permissions you assign and the Einstein Trust Layer. |
| AnalyticsTableau, Tableau Next, CRM Analytics | Data and analytics | Reports on shared metric definitions such as active customer and lifetime value. Reads data; owns only the definitions. |
| Sales and service teamsLightning, Slack, mobile | People | Work in CRM with the unified context surfaced on records, and decide on any agent action that needs human confirmation. |
| Customer channelsemail, web, app, messaging | Channel or touchpoint | Where customers see messages, offers and self-service. Content is chosen from consented data only. |
Data flows
- Sales and Service Cloud → Data 360: CRM data streams. Zero-cost connectors bring Sales and Service objects into Data 360 data streams. Monitor refresh history so a failed refresh is noticed.
- Commerce Cloud → Data 360: orders and shoppers. B2C Commerce has a Data 360 connector; other commerce data arrives through CRM objects or the integration layer. Orders arrive on each stream's refresh schedule.
- Marketing Cloud → Data 360: engagement data. Marketing Cloud Engagement has a Data 360 connector for engagement data. Marketing Cloud Next runs on the core platform with Data 360.
- Sales and Service Cloud → Marketing Cloud: contacts and tracking. Marketing Cloud Connect syncs chosen CRM objects on a polling interval and writes tracking data back to CRM. A paused sync leaves audiences stale.
- ERP and finance → Integration layer: invoices, credit, stock. APIs or files collected by middleware, validated and retried. Records that keep failing go to a dead-letter queue for review.
- Integration layer → Sales and Service Cloud: reference fields. Read-only summaries such as credit status or last invoice date, written to CRM by an integration user with least privilege.
- Data 360 → Agentforce: grounding context. Unified profile attributes and calculated insights made available to agents, subject to the agent user's permissions and Trust Layer masking.
- Data 360 → Analytics: harmonised data. Data model objects and calculated insights feed analytics, so metrics use the same identity and definitions as marketing.
- Sales and Service Cloud → Integration layer: record changes. Change Data Capture or platform events tell the integration layer when an account or order changes, so the ERP is updated without polling.
- Agentforce → Sales and service teams: answers and actions. Agents suggest or take actions. Write actions use confirmation steps and are logged.
- Agentforce → Customer channels: self-service. Customer-facing agents answer on web and messaging channels and hand over to a person when they should.
- Analytics → Sales and service teams: dashboards. Dashboards and embedded analytics in Lightning and Slack, filtered by each user's access.
Component responsibilities
| Component | Owns (system of record) | Reads from others | Notes |
|---|---|---|---|
| Sales and Service Cloud | Accounts, contacts, leads, opportunities, cases | Order summary, consent status, engagement summary | Usually one core org |
| Commerce Cloud | Baskets, orders, shopper accounts | Catalogue, pricing, customer identity | B2C Commerce, B2B Commerce and Order Management |
| Marketing Cloud | Sends, journeys, engagement events | Contacts, segments, consent | Engagement or Next; Next runs on the core platform |
| ERP and finance | Invoices, payments, credit, stock | Accounts, orders | External, behind the integration layer |
| Data 360 | Unified Individuals, calculated insights, segments | All sources above | Source data is not altered |
| Agentforce | Nothing as master | CRM records, Data 360 context | Acts only through permitted actions |
| Analytics | Metric definitions | All of the above | Tableau, Tableau Next or CRM Analytics |
Data flow, step by step
- Records are created where the work happens: leads and opportunities in Sales Cloud, cases in Service Cloud, orders in Commerce Cloud, invoices in the ERP.
- Data 360 ingests the sources. CRM, B2C Commerce and Marketing Cloud Engagement use Salesforce's zero-cost connectors; other sources use the Ingestion API, files or zero copy federation with warehouses such as Snowflake, Databricks, Redshift or BigQuery. Each stream is categorised as Profile, Engagement or Other, and its refresh mode cannot be changed after creation, so decide it up front.
- Streams are harmonised. Data lands in data lake objects (DLOs) and is mapped to data model objects (DMOs) in the Customer 360 Data Model.
- Identity is resolved. Match rules (exact, fuzzy and normalised) and reconciliation rules (most frequent, most recent or source priority) produce Unified Individuals, unified link objects and unified contact points.
- Insights and segments are built on unified profiles, then activated to Marketing Cloud or other targets, or exposed to Agentforce as grounding context.
- External data comes back as reference. ERP data reaches CRM through the integration layer as read-only fields, never as a second editable copy.
- Outcomes are measured in analytics, using one written definition per metric.
Trust boundaries and authentication
- The Salesforce org. People and integration users are governed by profiles, permission sets and sharing. Give each integration its own user with least privilege. Salesforce has said connected apps support ends in Summer '27, so build new integrations on External Client Apps. The OAuth username-password, user-agent and hybrid user-agent flows retire on 20 February 2027.
- Marketing Cloud Engagement is a separate tenant with its own users. Marketing Cloud Connect needs two system users: the MC Connect API user and a dedicated CRM API user.
- External systems sit behind the integration layer. Credentials live server-side in named and external credentials, never in code. See named credentials and external credentials explained.
- Agents run under the permissions you assign. The Einstein Trust Layer provides grounding, data masking, toxicity detection, an audit trail and zero data retention agreements with LLM providers. We start agents read-only and add write actions with confirmation.
Failure scenarios and how to handle them
| Scenario | Effect | Handling |
|---|---|---|
| Duplicate people across clouds | Inflated counts, double sends | Normalised match rules, source-priority reconciliation and data quality checks before identity resolution |
| Marketing Cloud Connect sync paused | Stale audiences | Monitor sync status and alert on lag; a synchronised data source can be paused but not deleted |
| ERP API unavailable | Reference fields go stale | Queue and retry in middleware, show a last-updated time, dead-letter after the retry limit |
| Identity rules over-merge | Two people share one profile | Test rules on real samples, start conservative and review unified link objects |
| Agent reads more than it should | Privacy exposure | Dedicated agent permission set, field-level security, Trust Layer masking and test prompts |
Operational monitoring
Watch Data 360 data stream refresh and identity resolution job history, Marketing Cloud Connect sync status, and integration throughput, error rate and dead-letter queue depth. For agents, Salesforce lists Agentforce Observability and Agent Health Monitoring; Event Monitoring in Shield (a separate licence) covers API and login activity. Our Data 360 jobs monitoring guide covers the detail.
Alternative approaches and trade-offs
- CRM as the hub, without Data 360. Simpler and cheaper to license. It works when CRM is the only real source, but unifying many sources in CRM objects becomes heavy.
- A warehouse or external CDP as the hub. Strong if your data team already runs one. Data 360 can work alongside it through zero copy instead of duplicating data. Compare options in Data 360 vs customer data platforms.
- Point-to-point integrations. Quick for two systems, brittle at five. See integration middleware vs point-to-point APIs.
Implementation checklist
- 01
Map entities and owners
Write an ownership matrix: for each entity and key field, one system of record and the systems that read it.
- 02
Confirm licences
Check Data 360 provisioning, Marketing Cloud edition, Marketing Cloud Connect requirements and Agentforce access with your Salesforce account team.
- 03
Decide the org strategy
Choose single or multiple orgs before building; see the multi-cloud architecture.
- 04
Define identity rules
Choose match keys and reconciliation rules and test them on real samples.
- 05
Put external systems behind a layer
Use middleware with retries, logging and a dead-letter queue.
- 06
Ground agents carefully
Give Agentforce a dedicated permission set and test with realistic prompts before go-live.
- 07
Agree metric definitions
Write down how active customer, churn and lifetime value are calculated.
Related services and solutions
Data 360 architecture
Data streams, identity resolution and activation in detail
→Identity and consent architecture
Identifiers, match rules and unsubscribe propagation
→Multi-cloud architecture
Several clouds, external platforms and org strategy
→Agentforce architecture
Agents, actions, grounding and guardrails
→Unified customer profile
Solution blueprint built on Data 360
→Data 360 consulting
Scoping, modelling and identity design
→Questions we hear
Is Customer 360 a product we can buy?
Do we need Data 360 for a single customer view?
Does Data 360 change our CRM records?
Can Agentforce update records?
Sources
- https://www.salesforce.com/products/
- https://www.salesforce.com/data/
- https://www.salesforce.com/aiforce/
- https://trailhead.salesforce.com/content/learn/projects/explore-data-cloud-core-functionality/unify-your-data
- https://trailhead.salesforce.com/content/learn/modules/marketing-cloud-connect/get-started-with-mc-connect
- https://developer.salesforce.com/docs/ai/agentforce/guide/trust.html
Plan your customer 360 architecture
We can map your systems of record, design the Data 360 and integration layers, and scope the build. Consultations are remote, from India.
