Salesforce Data 360 Architecture: Components, Data Flow, DLO, DMO, Identity Resolution & Activation

What Is Salesforce Data 360 Architecture?

Salesforce Data 360 architecture defines how data enters the platform, how it is stored and modeled, how records from different sources are unified, and how the resulting customer and business context is used for analytics, segmentation, automation, AI and activation.

The architecture is more than a database design.

It connects several capabilities:

• Data ingestion
• Data federation
• Data Lake Objects
• Data Model Objects
• Customer 360 Data Model
• Data transformation
• Identity resolution
• Unified profiles
• Calculated insights
• Data graphs
• Segmentation
• Activation
• APIs
• Data actions
• AI and Agentforce use cases

Salesforce describes Data 360 as an architecture for bringing together fragmented data, harmonizing it through a common data model, unifying identities and making the resulting information available for downstream actions.

The architecture therefore needs to answer a fundamental enterprise question:

How can an organization turn fragmented data from multiple systems into trusted, actionable customer context without creating another disconnected data silo?

Salesforce Data 360 Architecture at a Glance

A simplified architecture looks like this:

ENTERPRISE DATA SOURCES
┌──────────┬──────────┬──────────┬──────────┬────────────┐
│ Salesforce│   ERP    │ Website  │ Marketing│ Data Lake  │
│   CRM     │   SAP    │   Apps   │ Platforms│ Warehouse  │
└─────┬────┴─────┬────┴─────┬────┴─────┬────┴──────┬─────┘
│          │          │          │           │
└──────────┴──────────┴──────────┴───────────┘
↓
CONNECTORS / APIs / MULESOFT
↓
┌─────────────────────────┐
│  INGESTION / FEDERATION│
└────────────┬────────────┘
↓
┌─────────────────────────┐
│ DATA LAKE OBJECTS (DLO) │
└────────────┬────────────┘
↓
DATA TRANSFORMATION
↓
┌─────────────────────────┐
│ DATA MODEL OBJECTS      │
│        (DMO)            │
└────────────┬────────────┘
↓
CUSTOMER 360 DATA MODEL
↓
IDENTITY RESOLUTION
↓
┌───────────────────────┐
│   UNIFIED PROFILES    │
└───────────┬───────────┘
↓
┌────────────────┼────────────────┐
↓                ↓                ↓
DATA GRAPHS     CALCULATED INSIGHTS   SEGMENTS
│                │                │
└────────────────┼────────────────┘
↓
ACTIVATION
↓
┌──────────────┬──────────────┬──────────────┐
│ CRM / Sales  │ Marketing    │ Agentforce   │
│ Service      │ Commerce     │ AI / Apps    │
└──────────────┴──────────────┴──────────────┘

This architecture can be implemented using different combinations of ingestion, federation, transformation, identity resolution and activation depending on the organization's requirements.

The Core Layers of Data 360 Architecture

A useful way to understand Data 360 is to divide the architecture into nine layers:

1. Source systems
2. Integration and ingestion
3. Data Lake Objects
4. Data transformation
5. Data Model Objects
6. Identity resolution
7. Insights and unified data
8. Activation
9. Applications and AI

Each layer solves a different problem.

1. Source Systems

Data 360 typically sits above an existing enterprise technology landscape.

The source environment may include:

CRM

• Salesforce CRM
• Microsoft Dynamics 365
• Legacy CRM platforms

ERP

• SAP
• NetSuite
• Microsoft Dynamics
• Other ERP platforms

Marketing

• Marketing Cloud
• Marketo
• Email platforms
• Advertising platforms

Digital Channels

• Websites
• Mobile applications
• E-commerce platforms
• Customer portals

Service

• Contact centers
• Case management platforms
• Support applications

Data Platforms

• Snowflake
• Databricks
• BigQuery
• Amazon Redshift
• Data lakes
• Enterprise warehouses

Operational Systems

• Billing
• Payments
• Logistics
• Product usage
• Subscription management

The architecture should begin with a source-system inventory rather than immediately configuring Data 360.

2. Integration and Data Ingestion

The next layer determines how data enters Data 360.

Salesforce supports multiple approaches including:

• Data connectors
• APIs
• MuleSoft
• Batch ingestion
• Streaming ingestion
• Data federation
• Zero-copy patterns

Salesforce's current architecture documentation describes Data 360 as supporting ingestion and federation from multiple enterprise sources, with data organized through its data model after ingestion.

The choice depends on:

• Data volume
• Data velocity
• Latency requirements
• Source capabilities
• Data governance
• Existing integration infrastructure
• Cost
• Security requirements

A nightly financial dataset does not necessarily need a real-time architecture.

A customer interaction triggering an immediate AI response might.

That distinction should be made during architecture design.

3. Data Lake Objects: The Persistent Data Layer

One of the most important concepts in Data 360 architecture is the Data Lake Object, or DLO.

A DLO represents data brought into Data 360 and preserves the source-oriented representation of that information.

Salesforce describes DLOs as containers for data brought into Data 360.

The architecture can therefore be simplified as:

External Source → Data Stream → Data Lake Object → Data Modeling → Data Model Object

For example:

SAP Customer Data → SAP Data Stream → Customer DLO → Field Mapping → Account / Individual DMO

DLOs are important because they provide a layer between source-system data and the standardized Data 360 model.

4. Data Streams

Data streams represent the pipelines that bring source data into Data 360.

Salesforce describes data streams as data sources brought into Data 360. They can be based on batch or streaming data.

A simplified flow is:

Source System → Data Connection → Data Stream → DLO → Mapping → DMO

A data stream configuration needs to account for:

• Source
• Object
• Fields
• Data types
• Refresh pattern
• Data volume
• Key fields
• Mapping
• Data quality

Data streams are therefore an important architectural boundary.

5. Data Transformation

Raw source data is rarely ready for direct customer unification.

Organizations may need to:

• Clean values
• Standardize formats
• Convert data types
• Join datasets
• Remove invalid records
• Normalize addresses
• Standardize phone numbers
• Transform dates
• Create derived attributes

Data 360 supports data transformation capabilities that allow source data to be prepared before it is used downstream. Salesforce documentation also distinguishes batch and streaming transformation capabilities.

For example:

"VIVEK SHARMA" → Proper Case → "Vivek Sharma"

Or:

+91 98XXXXXXXX → Normalization → Standardized Phone

These seemingly small transformations can significantly affect identity resolution and segmentation quality.

6. Data Model Objects: The Harmonization Layer

After data enters Data 360, source-specific schemas need to be mapped into a common model.

This is where Data Model Objects, or DMOs, become important.

Salesforce describes DMOs as harmonized groupings of data created from data streams, insights and other sources.

The relationship is:

Source Schema → DLO → Field Mapping → DMO → Standardized Enterprise Meaning

For example:

CRM:

Customer_ID

ERP:

Customer_Number

Website:

User_ID

These may represent different source identifiers for related entities.

The Data 360 model provides a standardized structure through which these datasets can be related.

7. Customer 360 Data Model

The Customer 360 Data Model provides the standardized framework used to model customer and business information across Data 360.

Salesforce describes it as a way to reduce complexity when integrating data across cloud applications and to provide standardized data guidelines.

The model is organized into subject areas representing business domains such as:

• Customer information
• Product
• Engagement
• Orders
• Sales
• Service
• Marketing
• Identity

DMOs are the building blocks within those subject areas.

The model can also be extended through custom DMOs when the standard model does not represent a business requirement.

DLO vs DMO

One of the most common Data 360 architecture questions is the difference between DLO and DMO.

Salesforce explicitly states that data ingested through data streams is written to DLOs and then mapped to DMOs. Only mapped fields and objects with relationships can be used for segmentation and activation.

This distinction is critical when designing a Data 360 implementation.

8. Data Spaces

Large organizations may need to separate data logically.

Data 360 provides Data Spaces for organizing data for use cases such as:

• Profile unification
• Insights
• Marketing
• Regional data
• Business units
• Brands
• Environments

A data space can help organizations control which data is considered within a particular operational or analytical context.

For global organizations, this can be useful when the same Data 360 environment supports multiple business units or geographic operations.

However, data spaces should be designed intentionally.

Creating unnecessary partitions can make architecture and governance more complicated.

9. Identity Resolution

Identity resolution is one of the most important layers in Data 360.

Consider the following records:

CRM

Vivek Sharma

[email protected]

Marketing

Vivek Sharma

[email protected]

E-commerce

V Sharma

[email protected]

Support

Vivek S.

+91 XXXXX XXXXX

The systems may not use the same identifier.

Identity resolution determines which records relate to the same entity.

Salesforce describes identity resolution as the process of transforming disparate data from multiple sources into a unified profile.

Identity Resolution Architecture

A simplified flow is:

CRM Record

\

Marketing Record

\

Website Record ---> Match Rules ---> Unified Profile

/

Support Record

/

ERP Record

Identity resolution can use different matching approaches, including:

• Exact matching
• Normalized matching
• Fuzzy matching
• Source-based trust
• Attribute-based rules

The important architectural principle is that identity resolution should not be treated as an afterthought.

If identity design is weak, downstream segmentation and activation will also be weak.

Unified Profiles

After identity resolution, Data 360 can produce unified profile representations.

However, there is an important distinction.

A unified profile should not automatically be interpreted as a traditional master-data "golden record."

Salesforce's architecture documentation specifically explains that unified profiles serve as keys connecting matching source records rather than simply selecting one record and overwriting all others.

This matters because organizations may still need source-system data for specific business decisions.

For example:

• ERP remains authoritative for invoice status
• CRM remains authoritative for opportunity ownership
• Marketing remains authoritative for campaign engagement

The unified profile provides the relationship and context across those systems.

10. Data Graphs

A Data Graph brings together information from multiple Data Model Objects to create a more usable view of related data.

Salesforce describes Data Graphs as materialized views built from DMOs that can reduce the number of calls required and support near-real-time query responses.

For example:

Customer

+

Orders

+

Products

+

Support Cases

+

Engagement → Data Graph

This can be useful when an application or downstream process needs related customer context without repeatedly querying many separate objects.

11. Calculated Insights

Raw data does not always provide the metric a business actually needs.

Calculated Insights can create derived metrics such as:

• Customer lifetime value
• Total purchases
• Average order value
• Purchase frequency
• Customer satisfaction score
• Product engagement
• Revenue by account
• Recent engagement

Salesforce describes Calculated Insight Objects as multidimensional metrics calculated from Data 360 data.

A simplified architecture:

Orders

+

Transactions

+

Customer

+

Products → Calculated Insight → Customer Lifetime Value

This turns raw data into business-ready intelligence.

12. Segmentation

Once data has been modeled and unified, organizations can create segments.

Examples include:

• High-value customers
• Customers at risk of churn
• Recently active customers
• Customers who purchased product X
• Customers who have not purchased in 180 days
• Enterprise accounts with open service cases

Salesforce documentation notes that mapped objects and fields with the required relationships are used for segmentation and activation.

This means segmentation quality depends directly on upstream architecture.

Bad data model:

Bad segment

Good data model:

Reliable segment

13. Activation

The purpose of Data 360 is not simply to store data.

The data needs to become useful.

Activation can send customer information, segments, insights or actions into downstream environments.

Examples include:

• Salesforce Sales
• Salesforce Service
• Marketing Cloud
• Commerce
• External applications
• Webhooks
• Platform events
• AI agents

Salesforce's developer architecture describes data actions, calculated insights and engagement data as mechanisms that can trigger automation in Salesforce, Marketing Cloud or external systems.

The architecture therefore becomes:

Data → Unification → Insight → Decision → Activation → Business Action

14. Data 360 APIs

APIs provide programmatic access to Data 360 capabilities.

Salesforce documents API resources for:

• Queries
• Profiles
• Calculated insights
• Identity resolution rulesets
• Source records
• Metadata

The Data 360 API operates within the Data 360 tenant, while Connect API provides related capabilities from the Salesforce Platform.

This enables applications to interact with Data 360 without requiring every use case to be built directly inside the Salesforce UI.

15. Zero-Copy Architecture

Zero-copy architecture is particularly relevant for organizations that already have large data investments outside Salesforce.

Instead of copying every dataset into Data 360:

External Data Platform → Zero Copy → Data 360

Data 360 can reference or federate supported external data.

Salesforce documents zero-copy federation and connectors for external platforms, allowing organizations to leverage existing investments in data platforms.

This can be particularly useful when:

• Data volumes are very large
• The source warehouse is already authoritative
• Duplication is undesirable
• Existing analytics workloads need to remain in place

Zero-copy should still be evaluated against performance, governance, latency and downstream requirements.

16. Unstructured Data

Modern enterprise data is not limited to tables.

Organizations also have:

• PDFs
• Contracts
• Support transcripts
• Product documents
• Invoices
• Emails
• Knowledge articles
• Images
• Other documents

Data 360 architecture now includes capabilities for unstructured data alongside structured customer data.

Salesforce describes Unstructured Data Lake Objects as containers for references to unstructured content and explains that unstructured content can be processed for downstream search and AI use cases.

This is particularly important for AI architectures.

An AI agent may need both:

Structured data

Customer, order, account and service information.

Unstructured data

Policies, contracts, knowledge articles and documents.

Bringing those contexts together can provide richer grounding for AI applications.

17. Data 360 and Agentforce Architecture

Data 360 becomes particularly important when Salesforce AI and Agentforce are part of the architecture.

A simplified architecture is:

Enterprise Data → Data 360 → Unified Customer Context → Insights / Data Graphs / Knowledge → Agentforce → Reasoning + Action → CRM / Service / Marketing / External Systems

The key principle is:

AI quality depends heavily on the quality and accessibility of enterprise context.

An agent that only has access to a limited CRM record may not have enough context to answer a complex customer question.

Data 360 can provide broader context across multiple data sources.

18. Data 360 Architecture for Sales

A sales architecture may connect:

CRM

+

ERP

+

Website

+

Product Usage

+

Marketing Engagement → Data 360 → Unified Account / Contact → Revenue Insights → Sales Activation

Potential outcomes include:

• Better account intelligence
• More complete opportunity context
• Customer engagement visibility
• Product usage context
• Revenue insights
• Better prioritization

19. Data 360 Architecture for Customer Service

A service architecture could combine:

• CRM account
• Customer profile
• Orders
• Service cases
• Product ownership
• Warranty information
• Customer engagement
• Knowledge

The result can provide service teams with a broader customer context.

Customer → Orders + Cases + Products + Engagement → Data 360 → Unified Service Context → Agent / Service Representative

This can support more contextual service experiences.

20. Data 360 Architecture for Marketing

Marketing architecture often focuses on:

• Identity
• Engagement
• Transactions
• Preferences
• Behavioral data
• Customer lifecycle
• Segmentation

A typical flow is:

CRM

+

Website

+

Commerce

+

Marketing Engagement

+

Transactions → Data 360 → Unified Profile → Calculated Insights → Segment → Marketing Activation

This is particularly useful when marketing needs to move beyond isolated campaign data.

Data 360 Architecture for B2B Organizations

B2B architecture introduces additional complexity.

Instead of only asking:

Who is the customer?

Organizations may need to understand:

• Account
• Contact
• Buying committee
• Parent company
• Subsidiary
• Opportunity
• Contract
• Product
• Orders
• Service relationship

A B2B Data 360 architecture therefore needs relationships between multiple entities.

For example:

Parent Account → Subsidiary → Contacts → Opportunities → Orders → Service Cases

The Customer 360 Data Model provides standardized structures that can be extended for specialized enterprise requirements.

Data 360 Architecture for B2C Organizations

B2C architectures typically emphasize:

• Individual
• Contact points
• Devices
• Transactions
• Engagement
• Products
• Preferences
• Behavioral events

A simplified model might be:

Individual → Email + Phone + Device → Transactions → Engagement → Product Interaction → Unified Profile

Identity resolution becomes especially important because customers may interact anonymously before becoming known customers.

Salesforce Data 360 Architecture Best Practices

1. Design the Data Model Before Building Integrations

Do not start by connecting every available system.

First define:

• Business entities
• Relationships
• System ownership
• Required attributes
• Identity keys
• Activation requirements

Then build integrations around the model.

2. Avoid Creating Unnecessary Custom DMOs

The standard Customer 360 Data Model should be used wherever practical.

Create custom DMOs when the standard model genuinely does not represent the business requirement.

Salesforce supports custom DMOs for business-specific information.

3. Treat Identity as an Architectural Layer

Identity resolution should be designed early.

Document:

• Match attributes
• Matching rules
• Source priorities
• Normalization requirements
• Duplicate handling
• B2B/B2C identity relationships

4. Separate Ingestion From Activation

Data entering Data 360 does not automatically mean it should be activated everywhere.

Use clear rules for:

What enters?

What is unified?

What is calculated?

What is activated?

5. Use Real-Time Only Where It Matters

Real-time architecture can be valuable for:

• Customer interaction
• Fraud-related signals
• Personalization
• Immediate service actions
• AI context

It may be unnecessary for:

• Historical reporting
• Monthly financial data
• Archived records
• Non-critical analytics

6. Design for Observability

Monitor:

• Data freshness
• Ingestion failures
• Mapping errors
• Identity resolution quality
• Transformation failures
• Activation failures
• API usage
• Processing latency

A data platform without observability becomes difficult to trust.

7. Plan for Schema Evolution

Enterprise systems change.

Fields get:

• Added
• Removed
• Renamed
• Replaced
• Reclassified

Architecture should include a process for handling source-system changes without breaking downstream processes.

Common Salesforce Data 360 Architecture Mistakes

Mistake 1: Treating Data 360 as Just a Database

Data 360 is not simply another place to copy CRM data.

It includes:

• Data integration
• Data modeling
• Identity resolution
• Insights
• Segmentation
• Activation
• AI enablement

Architecture should account for the full lifecycle.

Mistake 2: Copying Everything

Not every enterprise dataset needs to be physically ingested.

Evaluate:

• Ingestion
• Federation
• Zero-copy
• APIs

based on the use case.

Mistake 3: Ignoring Source-System Ownership

If every system can update the same customer attribute, governance becomes difficult.

Define system-of-record ownership.

Mistake 4: Designing Identity Resolution Too Late

Identity resolution affects:

• Unified profiles
• Segments
• Analytics
• Personalization
• AI

It should be part of the initial architecture.

Mistake 5: Building Integrations Before Defining the Data Model

This often produces technically connected but semantically inconsistent data.

The better sequence is:

Business Requirements → Data Model → Identity Strategy → Integration Architecture → Data Ingestion → Activation

Mistake 6: Ignoring Downstream Activation

If the architecture only focuses on bringing data into Data 360, the organization may create a sophisticated data platform without creating measurable business value.

Always define where the data needs to go next.

Salesforce Data 360 Architecture Implementation Roadmap

A practical enterprise implementation can follow these phases.

Phase 1: Business Discovery

Document:

• Business objectives
• Priority use cases
• Stakeholders
• KPIs
• Data consumers

Phase 2: Source-System Assessment

Inventory:

• CRM
• ERP
• Marketing
• Service
• Commerce
• Data warehouse
• Data lake
• Digital platforms

Assess:

• Data quality
• Volume
• Frequency
• Ownership
• Integration capabilities

Phase 3: Target Architecture

Define:

• Ingestion
• Federation
• DLO strategy
• DMO strategy
• Data spaces
• Transformation
• Identity resolution
• Insights
• Activation

Phase 4: Data Model

Define:

• Standard DMOs
• Custom DMOs
• Relationships
• Identity attributes
• Keys
• Data quality rules

Phase 5: Integration

Configure:

• Data streams
• Connectors
• APIs
• MuleSoft
• Zero-copy connections
• Data transformations

Phase 6: Unification

Configure:

• Match rules
• Reconciliation rules
• Identity resolution
• Unified profiles

Phase 7: Insights

Build:

• Calculated insights
• Data graphs
• Segments
• Business metrics

Phase 8: Activation

Connect:

• Sales
• Service
• Marketing
• Commerce
• Agentforce
• External applications

Phase 9: Governance and Optimization

Continuously monitor:

• Data quality
• Integration performance
• Identity resolution
• Usage
• Security
• Business KPIs

Salesforce Data 360 Architecture Checklist

Strategy

• Business objectives defined
• Priority use cases identified
• KPIs established
• Data consumers identified

Data

• Source systems inventoried
• Data ownership defined
• Data quality assessed
• Identity attributes identified
• Data model designed

Architecture

• Ingestion strategy defined
• Federation strategy evaluated
• DLO strategy defined
• DMO strategy defined
• Data Spaces evaluated
• Transformation strategy defined
• Zero-copy opportunities evaluated

Identity

• Match rules defined
• Reconciliation rules defined
• Duplicate strategy defined
• Unified profile requirements defined

Activation

• Segments defined
• Calculated insights defined
• Data graphs evaluated
• Activation targets identified
• APIs evaluated
• Agentforce requirements considered

Operations

• Monitoring configured
• Error handling defined
• Schema-change process established
• Security controls implemented
• Governance model established

How MoreYeahs Can Support Data 360 Architecture

A Data 360 architecture needs to fit into the organization's existing Salesforce and enterprise technology landscape.

MoreYeahs' Salesforce services include Salesforce implementation, integration and managed services. The company states that it has developed integrations with SAP, NetSuite, Dynamics 365 and custom systems using real-time APIs, near-real-time middleware and batch patterns.

This type of integration experience is particularly relevant when Data 360 needs to connect Salesforce with existing ERP, CRM and custom application environments.

A practical architecture engagement can focus on:

1. Current-state architecture assessment
2. Source-system analysis
3. Data model design
4. Integration pattern selection
5. DLO and DMO design
6. Identity resolution strategy
7. Data quality framework
8. Activation architecture
9. AI and Agentforce readiness
10. Governance and optimization

The objective should not be to add another data platform.

It should be to create a connected architecture that makes existing enterprise data more useful.

Final Takeaway

The strongest Salesforce Data 360 architecture is not the one with the most integrations.

It is the one that creates the clearest path from enterprise data to business action.

A mature architecture looks like:

Sources → Integration → DLO → Transformation → DMO → Identity Resolution → Unified Profile → Insights → Segmentation → Activation → Business Action

Each layer has a specific responsibility.

DLOs preserve and organize incoming data.

DMOs provide standardized business meaning.

The Customer 360 Data Model establishes common structures.

Identity resolution connects records across systems.

Calculated insights and data graphs turn modeled data into usable context.

Segmentation and activation turn that context into action.

And APIs, integrations and Agentforce can bring the resulting intelligence into the applications where employees and customers actually interact.

That is the real value of Data 360 architecture.

It is not simply about bringing data together.

It is about creating a reliable architecture through which data can become context, context can become intelligence, and intelligence can become action.