How Do Salesforce App Containers and Data 360 Work Together?

As organisations modernise their Salesforce estates, a new design question keeps surfacing: what should live inside each application org, and what should move into the Data 360 layer? This is not a theoretical distinction. It affects data quality, system interoperability, automation design, and how confidently the enterprise can scale.

This article outlines a clear way to think about these boundaries. The goal is to help architects design cleaner, more predictable systems without depending on specific implementations or proprietary patterns.

Enterprise meaning vs local operational meaning

Modern enterprise architecture benefits from separating two different types of meaning:

Enterprise meaning

This is the shared definition of a business entity across teams, systems, and applications. Examples include:

• A unified customer profile

• A consistent global product definition

• Enterprise-level identity and relationships

This meaning must be stable, governed, and shared across applications.
In the Salesforce landscape, enterprise meaning belongs in Data 360, modelled as DMOs (Data Model Objects).

Local operational meaning

This reflects how an application org uses data to run its own workflows. Examples include:

• UI-driven fields

• process-specific attributes

• workflow routing data

• temporary or transitional data

These attributes vary from org to org and evolve with the operational needs of the team.
Local operational meaning belongs in the app org, stored in sObjects.

This distinction provides a durable, scalable boundary between application behaviour and enterprise identity.

When to use DMOs vs local sObjects

A practical and reliable rule is emerging:

• Use DMOs when the data must be understood or shared consistently across multiple applications.

• Use sObjects when the data exists only to support local processes inside that org.

DMOs carry the enterprise identity, harmonised attributes, and unified semantics.
sObjects carry the fields and objects required for UI, automation, and operational transactions.

Neither layer replaces the other.
Each has a clear purpose.

When to sync or cache

As Data 360 becomes the enterprise data backbone, architects must decide how applications consume that data.

Use selective sync into the org when:

• automation needs the data immediately

• the attribute affects workflow behaviour

• the UI must display the value without latency

Use no sync when:

• the data is not required for transactions

• the app only needs to reference the value inside Data 360

• the attribute is large or volatile

Use thin caching when:

• performance is essential

• the app needs a stable snapshot

• enterprise meaning still lives in the DMO

The emerging pattern is:

Store operational truth locally.
Store enterprise truth centrally.
Sync only what the application genuinely needs.

Clear separation of concerns

A modern estate works best when each layer carries a distinct responsibility:

App container (Salesforce org)

• App UI

• App Logic

• Local app data (sObjects)

• Local operational meaning

• Optional cached enterprise attributes

Data 360 (Enterprise data layer)

• DMOs as canonical enterprise meaning

• Semantic harmonisation

• Identity resolution

• Insight data and AI-derived signals

• Data federation for zero-copy access

• Data Spaces for governance, residency, and policy

This separation creates stability.
It allows orgs to evolve without breaking each other.
It ensures that enterprise meaning is consistent even as individual applications change.

A practical way forward

Most organisations will adopt these patterns gradually. They may start with a small set of entities in Data 360, or introduce DMOs for a single domain. Over time, more applications can align to the enterprise layer, reducing duplication and improving clarity.

The direction of travel is clear:
application logic belongs close to users; enterprise meaning belongs in the data layer.

Architects who design with this distinction in mind will build estates that are easier to govern, easier to extend, and better prepared for the next decade of Salesforce evolution.